On Wed, 15 Dec 2010, Henry Chan wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=618644
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11468
Consider a new web application that loads pages. All links are
transformed into ajax and storing the history data with pushState if the
I'm not sure I follow you here. My idea for option A is that you never
get a popstate when doing the initial parsing of a page.
Okay, I may still have misunderstood, despite my best efforts! :)
Option B:
Fire popstates as we currently do, with the caveat that you never
fire a stale
On Fri, Feb 11, 2011 at 12:25 AM, Justin Lebar justin.le...@gmail.com wrote:
I'm not sure I follow you here. My idea for option A is that you never
get a popstate when doing the initial parsing of a page.
Okay, I may still have misunderstood, despite my best efforts! :)
Option B:
Fire
The problem with option B is that pages can't display correctly until
the load event fires, which can be quite late in the game what with
slow loading images and ads. It means that if you're on a page which
uses state, and reload the page, you'll first see the page in a
state-less mode while
On Sun, Feb 6, 2011 at 10:18 AM, Justin Lebar justin.le...@gmail.com wrote:
1) Fire popstates as we currently do, with the caveat that you never
fire a stale popstate -- that is, if any navigations or
push/replaceStates have occurred since you queued the task to fire the
popstate, don't fire
1) Fire popstates as we currently do, with the caveat that you never
fire a stale popstate -- that is, if any navigations or
push/replaceStates have occurred since you queued the task to fire the
popstate, don't fire it.
Proposal B has the advantage of requiring fewer changes.
The more I
In terms of spec changes:
- Step 5 in
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#dom-history-replacestate
would be changed to set a flag if the ready state is not complete
- Same thing in step 11
I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat
surprising.
How is this better than never firing an initial popstate?
-Justin
On Mon, Jan 31, 2011 at 6:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Dec
On Wed, Feb 2, 2011 at 2:05 PM, Justin Lebar justin.le...@gmail.com wrote:
I'm a bit uncomfortable with this behavior, since it seems that having
replaceState cancel the initial popstate is at least somewhat
surprising.
How is this better than never firing an initial popstate?
My thinking
So during loading, any script that wants to know what the initial (or
current) state is does not need to wait for the first popstate, but
can simply grab the state and go.
Yeah, I think it's too late to move to this approach.
My thinking was that if someone calls replaceState, then probably
On Wed, Feb 2, 2011 at 2:34 PM, Justin Lebar justin.le...@gmail.com wrote:
So during loading, any script that wants to know what the initial (or
current) state is does not need to wait for the first popstate, but
can simply grab the state and go.
Yeah, I think it's too late to move to this
On 2011-02-02 23:48, Jonas Sicking wrote:
I think my latest proposed change makes this a whole lot better since
the state is immediately available to scripts. The problem with only
sticking the state in an event is that there is really no good point
to fire the event. The later you fire it the
Oh, I think I now understand what Jonas meant.
Proposal A, as I understand it:
1) Don't fire an initial popstate, because this causes stale popstates
when pushState is called before the popstate.
2) Expose the state object to the DOM so pages can find out what the
initial state is when they
Thanks, you save my life!!
Btw i'd reli like the onpopstate to fire as early as possible, possibly
before images are requested/dom is fully loaded. But this is already great
enough :D
On Tue, Feb 1, 2011 at 10:32 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Dec 23, 2010 at 6:18 PM,
On Thu, Dec 23, 2010 at 6:18 PM, Henry Chan
henry.fai.hang.c...@gmail.com wrote:
It fixes the bit where back/forward before onload doesn't fire onpopstate.
But no, it still doesn't let us detect inital onpopstate. And back/forward
buttons don't work properly until onload. A workaround would
On Sun, 19 Dec 2010 08:42:09 +0100, Henry Chan
henry.fai.hang.c...@gmail.com wrote:
*bump*
This is really serious, it blocks a very good use of the API, and it's
unreliable to use it if back and forward is clicekd before onload.
This got fixed, no?
*bump*
This is really serious, it blocks a very good use of the API, and it's
unreliable to use it if back and forward is clicekd before onload.
--
Henry Chan
henry.fai.hang.c...@gmail.com
Administrator of www.wyavtv.org
As mentioned in:
https://bugzilla.mozilla.org/show_bug.cgi?id=618644
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11468
I think the current behavior of onpopstate is very hard to understand. (And
I'm having trouble explaining it as well)
First off I'm going to use the term media heavy site as a
18 matches
Mail list logo
