[Webkit-unassigned] [Bug 145953] pushState and navigation sequence causes document to be requested when it shouldn't

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=145953

--- Comment #6 from Brady Eidson <beidson at apple.com> ---
Iraé, here's why I don't think this is a bug.

> 1. Go to page A, that implements history.pushState and history.replaceState.

Let's call URL-A "http://foo.com/index.html"

The WebView has only ever loaded a single document - DOC-A
The back/forward list has one entry:
URL-A (DOC-A)

> 2. Page A uses replaceState to store current page, creating PageA-state1

The WebView has still only ever loaded a single document - DOC-A
The back/forward list now has one entry:
URL-A (DOC-A, with state object A1)

> 3. Navigate internally using a link, that uses pushState...

Let's say the pushState is to URL-B "http://foo.com/bar.html"

The WebView has still only ever loaded a single document - DOC-A
The back/forward list now has two entries:
URL-A (DOC-A, with state object A1), URL-B (DOC-A, with state object B1)

>...does Ajax request then uses replaceState to create PageA-state2

The WebView has still only ever loaded a single document - DOC-A
The back/forward list now has two entries:
URL-A (DOC-A, with state object A1), URL-B (DOC-A, with state object B2)

> 4. Navigate to a different document.

Let's call the navigation to URL-C "http://webkit.org/"

The WebView has now navigated to TWO different documents, DOC-A and DOC-C
The back/forward list now has three entries:
URL-A (DOC-A, with state object A1), URL-B (DOC-A, with state object B2), URL-C (DOC-C)

At this point in time, DOC-A might no longer exist. If DOC-A was eligible to go into the page cache, then it still exists in a suspended state. But if something about DOC-A rendered it ineligible, it is gone. Forever.

> After a while, or after "minimizing Safari"...

"After awhile" might mean, say, 3 hours. At this point, even if DOC-A were still suspended in the page cache, we would've invalidated it. It is too old for us to confidently resume.

Or, if you minimize Safari and then go launch some other apps that use memory on your device, WebKit would get a low memory warning and purge DOC-A, since it is not obviously usable anymore.

> ...press back.

You are viewing URL-C (DOC-C), and you press back. If DOC-A still exists, the "back" command is telling WebKit "Resume DOC-A at URL-B, popping state object B2"

But if anything has happened to purge DOC-A, then the "back" command is telling WebKit "Load URL-B, then pop state object B2"

Your server is likely to actually get pinged for URL-B, since WebKit never actually loaded a URL-B - Remember the user originally visited "http://foo.com/index.html" yet now WebKit is being asked to load "http://foo.com/bar.html", which has never actually been loaded.

This is why when people use pushState/replaceState it is important that they use real world URLs. Those URLs are not meant to be some app-internal placeholder, but rather actually URLs that might actually be hit in a network request.

Does this explanation make sense to you? Is there anything else I can help clarify?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160112/892f4301/attachment.html>