History AWOL with YouTube "get more videos" button.

[Brian Durant]

Nexus 7 2013, Ubuntu Touch r2, dev channel.

There appears to be a browser bug, possibly connected to the YouTube "get more videos" button at the bottom of a page. When the button is pressed, no history is remembered and the video plays without a chance to choose whether HQ or not.

[Olivier Tilloy (osomon)]

Looking into what’s happening with youtube, it seems that when clicking on a video the page loads and all we get is a LoadCommitted event, never a LoadSucceeded, which explains why the browser doesn’t store the URL in the history database.

Adding an oxide task to get clarification from Chris: is it expected that some pages trigger only a LoadCommitted event (I’m not seeing any other events)? If so, do you reckon we should store URLs in the history db upon load committed, rather than load succeeded?

[Olivier Tilloy (osomon)]

<chrisccoulson> oSoMoN, if it's an "in-page" navigation (ie, only the URL fragment changes), then that's expected
<oSoMoN_> chrisccoulson, thanks, that’s what I suspected, I’ll update that code in the browser then
<chrisccoulson> oSoMoN_, saying that - do other browsers store history entries for in-page navigations?
<oSoMoN_> good question
 I don’t know
<chrisccoulson> It would be worth checking, although there isn't really a proper way for you to detect in-page navigations at the moment
<oSoMoN_> but remembering youtube videos in the browsing history is a pretty big use case, that I would expect browsers care about
<chrisccoulson> oSoMoN, I believe there's actually a test in oxide for this case as well
<chrisccoulson> Yeah, in tst_WebView_loading.qml (tests 6 and 7)
 I need to write API documentation :)

[Matthew Paul Thomas (mpt)]

There seem to be a few misunderstandings in this bug report:

* Choosing "Show more videos" at the bottom of a YouTube video page does not play a video, it just extends the list of videos. The video at the top of the page may start playing at about the same time as you click the button, but that's a coincidence. Absent steps to reproduce the bug, I suspect that button is a red herring.

* When you navigate between videos on YouTube, they auto-play in most browsers without letting you choose HQ first. That doesn't have anything to do with browser history either.

* The answer to Chris's question, "do other browsers store history entries for in-page navigations?" is "It depends which history you mean". Modern browsers have three classes of history:
- URL history per tab/window, as navigated through using Back and Forward buttons; which is a superset of
- page history per tab/window, as listed when holding down the Back and Forward buttons; which is a subset of
- global page history shared between tabs/windows, as listed in the History screen.
In-page navigation is included in only the first type of history. (Extending it to the other two would be interesting, but would require design work.)

* But that's not relevant to this bug report either, because YouTube does *not* use in-page navigation to navigate between videos. Look at the URL; there is no "#" fragment at any point.

One real bug here is that YouTube is using pushstate and popstate to navigate between videos, and the browser's global history does not recognize pushstate and popstate URLs, so you can't see the list of videos you viewed in the History screen. <http://diveintohtml5.info/examples/history/fer.html> is a simpler test case.

[Olivier Tilloy (osomon)]

Thanks for the detailed assessment mpt. So using pushState(), no load event is ever emitted, and thus the browser doesn’t get a chance to store the URL of the new video being played in the shared history database.

The very fact that pushState updates the URL seems to indicate that it is desirable to store that new URL in the shared database.

[Matthew Paul Thomas (mpt)]

Yes, the point of history.pushState and .replaceState is precisely to let Web developers manipulate the page history. That way a browser user can find and return to a page, even though on their previous visit it was generated client-side.

[Olivier Tilloy (osomon)]

> So using pushState(), no load event is ever emitted

Nevermind that comment, it is incorrect. When using pushstate(), a LoadCommitted event is emitted. This seems to indicate that we should indeed store entries in the shared history when getting LoadCommitted events, not LoadSucceeded. This is what the linked branch implements.

[Olivier Tilloy (osomon)]

In chrome, an entry is added/updated in the history database in HistoryTabHelper::DidNavigateAnyFrame(), which is called by content::WebContents::DidNavigateAnyFramePostCommit(), which itself is called by content::NavigatorImpl::DidNavigate(). This corresponds to a LoadCommitted event in oxide.

LoadCommitted events emitted by oxide originate from content::WebContents::DidCommitProvisionalLoad(), which is called by content::NavigatorImpl::DidNavigate().

This confirms that we should indeed store entries in the shared history when getting LoadCommitted events, not LoadSucceeded.

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+16.04.20160303-0ubuntu1

---------------
webbrowser-app (0.23+16.04.20160303-0ubuntu1) xenial; urgency=medium

  [ CI Train Bot ]
  * Resync trunk.

  [ Olivier Tilloy ]
  * Refer to @{XDG_DOWNLOAD_DIR} in the browser’s apparmor profile
    instead of hardcoding "Downloads" in English. (LP: #1535666)
  * Store entries in the history database on load committed, not load
    succeeded. This ensures that content-initiated navigations are also
    stored. (LP: #1455858, #1549780)
  * Update translation template.
  * Visual tweaks per designers’ review.

 -- Olivier Tilloy <email address hidden> Thu, 03 Mar 2016 19:01:40 +0000