Re: [whatwg] Question about pushState

[Darin Fisher]

As follow-up, I've filed these bugs:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8629
https://bugs.webkit.org/show_bug.cgi?id=33160

(Privately, Maciej Stachowiak told me that he supports changing WebKit's
pushState implementation to match Firefox, and so I have filed a bug against
the spec to get it updated to reflect what implementors are doing.)

-Darin



On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:

> [Apologies if this has been discussed before, but I couldn't find it in the
> archives.]
>
> Why does pushState only prune forward session history entries corresponding
> to the same document?  I would have expected it to behave like a reference
> fragment navigation, which prunes *all* forward session history entries.
>  Reason: it seems strange when a "navigation" doesn't result in a disabled
> forward button in the browser UI, so an app developer may be unsatisfied
> using pushState in place of reference fragment navigations.
>
> Thoughts?
> -Darin
>

Re: [whatwg] Question about pushState

[Jonas Sicking]

On Wed, Dec 16, 2009 at 10:25 PM, Justin Lebar  wrote:
> On Wed, Dec 16, 2009 at 3:06 PM, Jonas Sicking  wrote:
>> On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:
>>> I would have expected it to behave like a reference
>>> fragment navigation, which prunes *all* forward session history entries.
>>
>> I agree. I *think* what you are suggesting is what the implementation
>> that Justin Lebar has written for Firefox does.
>
> Yes, with my patch, the forward button is never active after a
> pushState.  It wasn't an intentional deviation from the spec, but I
> agree with Darin's reasoning: If pushState is a replacement for the
> hash-navigation hack, then it should behave like a hash navigation.

I rather think of it as pushState is a way to do AJAX navigation
similar to normal navigation. And with normal navigation you loose all
your forward history.

/ Jonas

Re: [whatwg] Question about pushState

[Justin Lebar]

On Wed, Dec 16, 2009 at 3:06 PM, Jonas Sicking  wrote:
> On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:
>> I would have expected it to behave like a reference
>> fragment navigation, which prunes *all* forward session history entries.
>
> I agree. I *think* what you are suggesting is what the implementation
> that Justin Lebar has written for Firefox does.

Yes, with my patch, the forward button is never active after a
pushState.  It wasn't an intentional deviation from the spec, but I
agree with Darin's reasoning: If pushState is a replacement for the
hash-navigation hack, then it should behave like a hash navigation.

-Justin

Re: [whatwg] Question about pushState

[Jonathan 'J5' Cook]

Jonas Sicking wrote:

On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:
  

[Apologies if this has been discussed before, but I couldn't find it in the
archives.]
Why does pushState only prune forward session history entries corresponding
to the same document?  I would have expected it to behave like a reference
fragment navigation, which prunes *all* forward session history entries.
 Reason: it seems strange when a "navigation" doesn't result in a disabled
forward button in the browser UI, so an app developer may be unsatisfied
using pushState in place of reference fragment navigations.
Thoughts?



I agree. I *think* what you are suggesting is what the implementation
that Justin Lebar has written for Firefox does.

/ Jonas
  
I would think that the behavior has to do with the definition of URL/URI 
and URL/URI fragment.  Moving backwards inside a page is considered 
navigation inside the URL/document (think scrolling in a page that is 
not enhanced), AFAICT.


J5

Re: [whatwg] Question about pushState

[Darin Fisher]

On Wed, Dec 16, 2009 at 12:06 PM, Jonas Sicking  wrote:

> On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:
> > [Apologies if this has been discussed before, but I couldn't find it in
> the
> > archives.]
> > Why does pushState only prune forward session history entries
> corresponding
> > to the same document?  I would have expected it to behave like a
> reference
> > fragment navigation, which prunes *all* forward session history entries.
> >  Reason: it seems strange when a "navigation" doesn't result in a
> disabled
> > forward button in the browser UI, so an app developer may be unsatisfied
> > using pushState in place of reference fragment navigations.
> > Thoughts?
>
> I agree. I *think* what you are suggesting is what the implementation
> that Justin Lebar has written for Firefox does.
>
> / Jonas
>


Hmm... the WebKit implementation appears to do as spec'd.

-Darin

Re: [whatwg] Question about pushState

[Jonas Sicking]

On Wed, Dec 16, 2009 at 11:51 AM, Darin Fisher  wrote:
> [Apologies if this has been discussed before, but I couldn't find it in the
> archives.]
> Why does pushState only prune forward session history entries corresponding
> to the same document?  I would have expected it to behave like a reference
> fragment navigation, which prunes *all* forward session history entries.
>  Reason: it seems strange when a "navigation" doesn't result in a disabled
> forward button in the browser UI, so an app developer may be unsatisfied
> using pushState in place of reference fragment navigations.
> Thoughts?

I agree. I *think* what you are suggesting is what the implementation
that Justin Lebar has written for Firefox does.

/ Jonas