[Webkit-unassigned] [Bug 145953] New: 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

            Bug ID: 145953
           Summary: pushState and navigation sequence causes document to
                    be requested when it shouldn't
    Classification: Unclassified
           Product: WebKit
           Version: 528+ (Nightly build)
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: History
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: irae at irae.pro.br

When using `window.history.pushState` on Mobile Safari, iOS 7, iOS 8 or iOS 9, and doing the following sequence, webkit is starting a request to the server and rebuilding the document when it shouldn't.


Steps to reproduce (just for the record, but contained in the example below):
1. Go to page A, that implements history.pushState and history.replaceState.
2. Page A uses replaceState to store current page, creating PageA-state1
3. Navigate internally using a link, that uses pushState, does Ajax request then uses replaceState to create PageA-state2
4. Navigate to a different document. After a while, or after "minimizing Safari", press back

Expected: PageA context should be restored, pop state event to fire, and restore to PageA-state2
What's happening: URL that was pushed during step 3 is requested and PageC is constructed from scratch.

I talked to Brady Eidson on WWDC 2015 Lab Sessions and we were able to reproduce. He created a minimal version but the exact conditions were not super precise.
I am submitting additional details here, and I uploaded an example case here:

https://github.com/irae/pushstate-bugs

During the Safari Labs at WWDC Brady suspected it was a process communication issue, but I believe it's something related to serialization to disk of the history states.
If I load the example on testing devices (which don't have anything special, not even apps installed), the but is not possible to reproduce right away. On the other hand, if you put Safari to background and come back, it triggers the error 100% of the times.

Another way of reproducing the error is to hold your finger on the back button and selecting the entry from the list.
For good measure I tested also Firefox, Chrome and Safari desktop. Chrome has a similar bug, which I will be submitting, but Safari on desktop and Firefox never hit the server for the URL that is not expected to be requested.

-- 
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/20150613/bc718074/attachment-0001.html>