Bug 35547 – Clicking the same named anchor twice in a row fails the second time

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Nate Chapin]

Originally reported at http://crbug.com/31851.

Repro steps:
1. Go to http://en.wikipedia.org/wiki/WebKit
2. Click on "Usage" link in the Contents at the top of the page
3. Scroll back to top of the page
4. Click "Usage" again

Step 4 should result in navigating back to the #Usage anchor, but nothing occurs.

I believe this is a regression due to http://trac.webkit.org/changeset/51644.  We don't scroll to the anchor if there isn't a hash change, which means we don't handle the case where we navigate, scroll, then navigate back to the same fragment.

I have a fix and layout test ready and will upload momentarily.

[Nate Chapin]

Created attachment 49755 [details]
patch

[Kenneth Rohde Christiansen]

Comment on attachment 49755 [details]
patch


> +    // We need to scrool to the fragment whether or not a hash change occurred, since

I guess that should be "scroll" :-) You should fix that before landing.

[Nate Chapin]

(In reply to comment #2)
> (From update of attachment 49755 [details])
> 
> > +    // We need to scrool to the fragment whether or not a hash change occurred, since
> 
> I guess that should be "scroll" :-) You should fix that before landing.

http://trac.webkit.org/changeset/55555

[Brady Eidson]

As far as I can tell, this change violates the HTML5 navigation spec:

The section "Navigating to a fragment identifier" invokes "History traversal".  History traversal has the following steps:

6 - If the specified entry has a URL that differs from the current entry's only by its fragment identifier, and the two share the same Document object, then let hash changed be true, and let old URL be the URL of the current entry and new URL be the URL of the specified entry. Otherwise, let hash changed be false.
...
8 - If hash changed is true, then, if the new URL has a fragment identifier, scroll to the fragment identifier.

Since hashchange is false, there should be no scroll.

---

All of that said, I think the new behavior is sensible, and it matches previous WebKit, Firefox, and Opera.  But my original change wasn't an accidental change in behavior, it was willfully following the spec.  I didn't realize at the time that it was breaking this fundamental case.

I think the spec needs to be changed to reflect this, but until it is changed, WebKit (and other browser engines) are out of spec.  :)

[Brady Eidson]

I brought this to Hixie's attention.  He filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=9193 to fix the spec.

All is well.