The default bug view has changed. See this FAQ.

Implement HTML5-compliant navigation to fragment

NEW
Unassigned

Status

()

Core
Document Navigation
7 years ago
6 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

(Depends on: 1 bug, {html5})

Trunk
html5
Points:
---

Firefox Tracking Flags

(blocking2.0 -)

Details

(URL)

(Reporter)

Description

7 years ago
Web compat requires percent encoding in the fragment id of a URL to match similarly percent-encoded name attribute value on the <a> element.

Gecko's old HTML parser special-cases the name attribute on <a> to make this work. HTML5 puts the special behavior on the URL processing side at the time of the navigation.

To avoid breaking stuff, we should be HTML5-compliant of both sides (parser and navigation). Currently, only the parser side is compliant. See bug 436006 comment 17.
Making the navigation compliant involves things like bug 483660 (hello, possibly web-incompatible change!), last I checked.  Also see bug 436006 and bug 483304.

By some beta we need to do something here: either fix bug 483660 and audit all consumers and fix them as needed, or change the HTML5 parser behavior.  Questions are:

1)  Which beta.
2)  Who's going to do it?
Depends on: 483660
I guess a third option is somehow revamping how we do navigation so that scrolls to anchor don't involve URIs... but that would only work for same-page anchors anyway.
(Reporter)

Comment 3

7 years ago
(In reply to comment #1)
> 2)  Who's going to do it?

Not me in the Firefox 4 timeframe. I guess this means that I'll have add the old Geckoism to the HTML5 parser for now. :-(
(Reporter)

Comment 4

7 years ago
(In reply to comment #3)
> (In reply to comment #1)
> > 2)  Who's going to do it?
> 
> Not me in the Firefox 4 timeframe. I guess this means that I'll have add the
> old Geckoism to the HTML5 parser for now. :-(

Filed bug 582940 about the contingency plan in case we don't find Someone Else to fix this bug in time for Firefox 4. (I want to work on this bug, but I'm guessing I won't have the time in the Firefox 4 timeframe.)
Not blocking on this, but bug 582940 does block.
blocking2.0: ? → -
You need to log in before you can comment on or make changes to this bug.