Distinguishing between navigation and history.pushState

[Vincent Scheib]

I'm seeking a way to determine that navigation has occurred and actually changed the document. http://crbug.com/138324

Currently, Fullscreen Controller observes content::NOTIFICATION_NAV_ENTRY_COMMITTED and uses (details)->is_navigation_to_different_page(). However, history.pushState triggers this, too.

The problem is that history.pushState also triggers that notification, and in that situation we do not want to exit full screen.

Any help finding the right logic to detect this appreciated.

[Jochen Eisinger]

A navigation that changes the frame is always preceded by the start of a provisional load. If you just see a commit but no start, the location is updated (happens for reference fragment navigations and history state changes). See WebNavigationTabObserver::DidCommitProvisionalLoadForFrame

best

-jochen

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Darin Fisher]

We should probably add a "IsWithinDocumentNavigation" or "IsSameDocument" method to NavigationEntry to help distinguish these cases.  We probably don't want code to be inferring this condition when WebKit knows it precisely.

-Darin

[Michael Nordman]

On Mon, Jul 23, 2012 at 11:57 AM, Darin Fisher <da...@chromium.org> wrote:

We should probably add a "IsWithinDocumentNavigation" or "IsSameDocument" method to NavigationEntry to help distinguish these cases.  We probably don't want code to be inferring this condition when WebKit knows it precisely.

+1, IsFragmentNavigation()?

[Jochen Eisinger]

On Mon, Jul 23, 2012 at 9:09 PM, Michael Nordman <mich...@google.com> wrote:

On Mon, Jul 23, 2012 at 11:57 AM, Darin Fisher <da...@chromium.org> wrote:

We should probably add a "IsWithinDocumentNavigation" or "IsSameDocument" method to NavigationEntry to help distinguish these cases.  We probably don't want code to be inferring this condition when WebKit knows it precisely.

+1, IsFragmentNavigation()?

that would be NavigationControllerImpl::IsURLInPageNavigation, no?

The history navigation case is differently, as you can't detect it from just looking at the URL.

-jochen

[Michael Nordman]

I see... i spoke too quickly w/o being familiar enough with these abstractions... it's not clear to me how to best reflect this state between NavigationController and NavigationEntry and NavigationDetails and such... but +1 an accessor that allows a caller to determine after the fact when a navigation is the the result of pushState vs other cases w/o having to monitor for commit w/o a provisional load on their own.

[Darin Fisher]

WebCore uses terms like "didNavigateWithinPage" and "loadSameDocumentItem" to refer to navigations that are either hash changes or induced via pushState/replaceState or popstate events.

The key thing that makes pushState introduce bugs is that it isn't just about changing the hash fragment.  In fact, in many cases it is now a bug if you just compare URLs sans-reference fragment.  The only code that should be doing that is the code in WebCore that tests to see if it should scroll to an anchor!

-Darin