[Bug 11468] spec logic: replaceState before onload should not affect onload object or popstate should not fire after onload.

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11468

henry.fai.hang.chan@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |

--- Comment #3 from henry.fai.hang.chan@gmail.com 2010-12-14 06:02:39 UTC ---
I don't understand how Example [2] is fixed.  It actually broke with the new
spec as replaceState when called before onload changes onpopstate event state.
Which causes index.html to get loaded again.

> Example[1] is working as intended.
> Just make the page load minimal, immediately replaceState() and then load the 
> page from the popstate event. (You can include all the data in the initial 
> connection so that the latency is no worse.)

Load minimal? The most minimal version i made still takes 3 seconds to load on
New Zealand as our server is in Hong Kong.  The user could still click within
this period and onpopstate after onload would fire with the new event state if
i used replaceState before onload.

> Alternatively, keep track of what the current state is and just don't do
> anything if reloading the current state (and use replaceState() when the page
> loads to track what the first state is).

Isn't that more code?

The actual solution I am proposing is, onpopstate should refer to the event
state at the BEGINNING of the navigation, i.e. after onload always fires with
event state null no matter if replaceState or pushState is called before
onload.

This works within Google Chrome (so-called "stable") already.

And reduces code. Of course an extra variable isn't much in terms of memory in
this modern world. But why make an extra variable when it could be altogether
avoided?

If i need to implement this extra variable, I might just go with onhashchange
altogether.  I don't see any advantage other than prettier urls.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 14 December 2010 06:02:41 UTC