36826 - named anchors no longer work

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Tobias Burnus]

Using the M16-snapshoot build from 2000-04-21-13 this doesn't work any more:
<h2 id="foo">...</h2> <a href="#foo">foo</a>. In stead of scrolling down to the
correct item, only the page is reloaded. (This worked a few days ago ok!)

Tobias

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Confirming bug.  This is true of both named anchors to id="" and <a name=""> in
Linux mozilla 2000-04-21-08-M16.  See, for example:
http://www.people.fas.harvard.edu/~dbaron/sat/eur/index.html (name attribute)
http://www.people.fas.harvard.edu/~dbaron/css/user/cascade (id attribute)

Nominating for nsbeta2 because this is a major feature and marking as
regression.  cc:ing travis because this seems kinda like
webshell/docshell/uriloader territory, but I'm not sure.

Comment 2

[Sean Richardson]

Confirming on WinNT with 2000-04-22-08-M16; Setting Platform/OS to All/All.

It is possible that this is a urlparser problem; Cc-ing [e-mail].

Comment 3

[rickg]

Gagan: this is not likely a top-level parser problem. Would you mind taking a 
look to triage the problem? Thanks.

Comment 4

[Gagan]

rick: I think someone in the layout might be a better candidate to triage this.
back to you. 

Comment 5

[Gagan]

*** Bug 36443 has been marked as a duplicate of this bug. ***

Comment 6

[Sean Richardson]

*** Bug 37229 has been marked as a duplicate of this bug. ***

Comment 7

[Andreas Otte]

*** This bug has been marked as a duplicate of 36104 ***

Comment 8

[Tobias Burnus]

Since the BUG 36104 is closed with "Verified works-for-me", which I cannot
change, I reopen this bug.
Note: <a name="foo"> works (with reloading), <... id="bar"> doesn't work.

Comment 9

[Hixie (not reading bugmail)]

This is a good test case for this:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/anchor2.html

It appears that "name" works, but not "id". Trying "Layout" component since
Rick doesn't want this.

Comment 10

[Marc Attinasi]

name attribute works, id attribute does not.

The main problem is in HTMLContentSink::ProcessATag: it only looks at the name 
attribute when determining if it is a named anchor. Later, when ScrollToRef is 
called the mRefContent is not set (since ProcessATag did not consider the id 
tag) and ScrollToRef aborts. Changing the ProcessATag method to check for the ID 
attribute makes Ian's test case for ID attribute work, however the way the 
HTMLContentSink is setup there can only be one mRefContent, so an anchor with 
the name and id set will only match whichever is checked for first. I tried a 
simple change to set two mRefContent members and that works, but I want the sink 
owner to look it over.

assigning to harish - Please check my patch and see if you like it or if you 
have a better way to handle the problem.

BTW: the jump to a named BR in the testcase does not work at all - is this a 
separate bug?

Comment 11

[Marc Attinasi]

Attachment: Patch to support named link based on ID attribute as well as name attribute

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm somewhat curious as to why this needs to be done, since I thought we already
supported ID attributes for named anchors.   Oh well...

Comment 13

[Hixie (not reading bugmail)]

The problem with jumping to a <br> with an id will be automatically fixed when 
bug 38370 is fixed.

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

But there ought to be a much easier way of fixing it than completely rewriting
the way BR works...

Comment 15

[harishd]

This should probably go to jst. 

Comment 16

[Tobias Burnus]

I think this is working now (2000-05-24-20) -> FIXED??
At least with my page it works (using <h2 id="">) Don't know whether it works
with all <br id=""> etc cases though.

Comment 17

[Nisheeth Ranjan]

Re-assigning to myself to reduce Johnny's nsbeta2+ list...

Comment 18

[Nisheeth Ranjan]

Yes, this is working for me, too, on today's NT debug build.  Marking 
WORKSFORME.

Comment 19

[Chris Petersen]

Fixed in the May 30th builds.

Comment 20

[Nicholas Cull]

Attachment: Test case: destination containing id, destination for next attachment

Comment 21

[Nicholas Cull]

Attachment: Testcase: contains destination id for next testcase

Comment 22

[Nicholas Cull]

Attachment: Testcase: link to id in previous testcase file

Comment 23

[Nicholas Cull]

Reopening bug.

ids are still problematic when linking to them from a different page. As a test 
case, attachment 11626 [details] contains a link to an id in attachment 11625 [details]. Selecting 
this link should go to attachment 11625 [details] and scroll down to the "expanded" year. 
Instead, the attachment appears, but doesn't scroll.

What's interesting is that if you go to attachment 11625 [details] directly and select 
the "Go to expanded branch" link, the page will scroll correctly.

Another thing to notice is that if you use the link from attachment 11626 [details], and 
then use the "Goto expanded branch" link, the back button no longer works.

Seeing this behaviour on Mozilla builds 2000071708 and 2000071920 on Windows NT 
4 Workstation.

Oh, please ignore attachment 11624 [details]. It has a weird rendering bug after the DIV. 
I'll create another bug report for that.

Comment 24

[Nisheeth Ranjan]

The problem related to scrolling to a named anchor after a page load is covered 
by bug 45338 which is nominated for a fix for beta 3.  Please file a new bug for 
the problem with the back button and assign it to the session history component.

I'm closing this bug.

Comment 25

[Chris Petersen]

Marking verified per last comments.