On 1/29/10 3:32 AM, Ian Hickson wrote:
On Wed, 27 Jan 2010, Darin Fisher wrote:
I think that location.hash = 'a' should synchronously add "#a" to the
session history, or at least it should appear to the web page that it
was added synchronously.
[...]
That said, I think it would be good for location.hash = 'a' to interrupt
the history.back() request. The net result being that "#a" is appended
to session history, and the history.back() request is discarded.
[...]
I'm trying to treat history,{back,forward,go} as a UI command to the
navigator. Synthesize the user clicking on the corresponding
back/forward buttons. UI actions typically do not get dispatched during
JS execution (ignoring window.showModalDialog of course).
[...]
I agree that we should not change the location without traversing
history.
I'm arguing for making history.{back,forward,go} start out by
dispatching a task to then run the history traversal algorithm. So,
history.back() would never change the location synchronously.
I've tried to spec this. There is a high risk of compatibility issues, so
I would very much welcome feedback from implementors who try to implement
this.
The main goal of the change here is to make it possible to implement this
(if not completely sanely, but it's the Web, there's only so much I can
do) in a situation with each browsing context having its own process, as
seen to some extent in IE and Chrome, and as is being examined by other
browser vendors also.
So why sync history isn't possible in IE or Chrome?
I have seen some arguments why it is perhaps hard to implement, but
not possible at all?
While I was at it I made 'hashchange' and 'popstate' fire completely
async, and gave 'hashchange' context information to get around the problem
with it firing async (where it could e.g. fire twice for the same URL,
because the navigations get processed before it fires).
On Thu, 28 Jan 2010, Olli Pettay wrote:
On 1/28/10 7:15 AM, Darin Fisher wrote:
That said, I think it would be good for location.hash = 'a' to
interrupt the history.back() request. The net result being that "#a"
is appended to session history, and the history.back() request is
discarded.
Really? What if iframe has been navigated lately and something calls
history.back() (to load previous page in iframe), but right after that
top level page calls location.hash = "foo";
Per spec now, any code along the lines of:
history.back();
location.hash = "foo";
...will cause the back() to be a no-op. This is definitely incompatible
with legacy implementations; the question is whether there are pages
depending on it.
How should UA handle this case? User presses back (which hopefully
does pretty much the same as history.back()) but web page has some
loop like script which sets location.hash all the time.
Depending on the script state, back might not succeed?
Or does location.hash = "foo"; not clear the history tasks if
back()/forward() was caused by the UA/user.
I know there is "When the user navigates through a browsing context,
e.g. using a browser's back and forward buttons, the user agent must
traverse the history by a delta equivalent to the action specified by
the user." but that doesn't quite clarify the situation, I think.
If we can't do this asynchronously, it's going to really suck for
multiprocess UAs,
Depends for example on whether UA wants to put different domains in
same tab to different processes. And even if it does do, synchronous
back()/forward() should be possible. Maybe just not as easy.
So I'm not sure that "suck for multiprocess UAs" is a really good
argument here.
so I think it's worth trying to find a solution here,
even if there is a back-compat risk. In practice I don't think the risk
is as high as it could be, because interop is pretty poor in this area
already; in particular, Chrome does things that are quite drastic when
given code like the above, and Chrome developers aren't aware of having
received bugs about it.
Again, please send feedback on this. The diff is:
http://html5.org/tools/web-apps-tracker?from=4631&to=4632
Uh, changing hashchange again to async. We must stop changing that all
the time. Though in this case I like the change. I never really
understood the sync hashchange, or the reasoning why it was changed to
be sync.
So history.back(); history.back(); would queue 2 tasks?
And first one document is loaded (maybe from bfcache), and it could
synchronously do something like dispatch pageshow or whatever which
could do things like alert() and then second document was loaded at
somepoint. Kind of strange way to handle history.back().
-Olli
