[whatwg] history.back()

[Olli Pettay]

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