31588 - Clicking on text in named anchor jumps to top of anchor when anchor is not terminated

Status: VERIFIED DUPLICATE of bug 31594

(Core :: DOM: HTML Parser, defect, P3)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Go to http://www.freei.net/ffaq.htm
2. Scroll down to the first paragraph below the table of contents
3. Click on some text in the middle of the paragraph

Result:
Browser jumps up to near the top of the page.

Possibly related to Bug 29416.

Comment 1

[Jesse Ruderman]

Attachment: Simplified test case

Comment 2

[Jesse Ruderman]

http://www.freei.net/ffaq.htm has an unclosed <a name="top"> tag near the top, 
and that's what's causing the problem.  The paragraphs after the first three 
are excluded because they're below a table (I have no idea why this excludes 
them, though).

Comment 3

[Jesse Ruderman]

Changing summary from "Clicking in paragraph below named anchor jumps to top" 
to "Clicking on text in named anchor jumps to top of anchor".

Comment 4

[Jesse Ruderman]

The editor, interestingly, does include the text under the table as part of the 
link (which it shows as underlined).  The table only stops named anchors (not 
hrefs) and only in the mozilla browser.

Comment 5

[Jesse Ruderman]

Filed to editor bugs using the same testcase: bug 31592 and bug 31594.

Comment 6

[Ryan Massie]

Confirming, nice test case. Changing component to parser. Is this right?

Comment 7

[Charles Manske]

Anchor should be terminated with </a> to prevent this. 
Not sure why there's a difference with browser behavior.

Comment 8

[Jesse Ruderman]

I don't think it's limited to non-terminated <a> tags.  Try adding a </a> at 
the bottom of the test case -- I think the same things happen.

Comment 9

[Charles Manske]

Yes, but my point is that the correct HTML syntax for named anchor should 
always have </a> immediatley following the <a>. The test case is definitely
incorrect. This bug is essentially invalid, but I plan to send it off to
layout for the issue that there's a difference in parsing between browser
and editor. The parser should automatically "insert" the </a> when it is 
missing as a "bad HTML fixup".

Comment 10

[Charles Manske]

The fact that it underline text between <a> and </a> (bug 31594) means it is
treating this as a link. Thus this behavior is expected.

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

Comment 11

[Alan S. Jones]

verified dupe