64250 - <font><a href><font>: link split before second <font> (was: Tabbing thru links, focus occasionally disappears)

Status: VERIFIED FIXED

(Core :: DOM: HTML Parser, defect)

Description

[Aaron Leventhal]

On Google, press tab 5 times.
1st tab: moves to "Google Search" button
2nd tab: moves to "I'm feeling Lunchy" button
3rd tab: moves to "Advanced Search" link
4th tab: moves to "Preferences" link
5th tab: focus is gone!

One more tab it goes where you thought it would for tab #5

Comment 1

[saari (gone)]

undoubtly this is a dup of another more specific bug, but I'll need to
investigate to find out which one.

Comment 2

[Jesse Ruderman]

Attachment: testcase

Comment 3

[Jesse Ruderman]

According to javascript:alert(document.body.innerHTML), Mozilla is splitting 
the link before the inner <font>.  The two parts of the link then take up two 
slots in the tab order for the page.

-> Parser (should I reassign to the parser people?)

Comment 4

[Stephen Ostermiller]

Another page that seems to have the same problem:
http://www.cs.princeton.edu/~appel/modern/java/

<font color="#006000">Modern Compiler Implementation <a href="../c">in
C</font></a><br>

<h3><a name=software>Software</a></h3>
<ul>
<li><a href="http://java.sun.com/products/JDK/">Java (tm) Developers Kit</a>
<li><a href="JLex"><strong>JLex</strong> lexical analyzer generator</a>
<li><a href="CUP"><strong>CUP</strong> parser generator</a>

All the links after the first one from this fragment seem to have the url of the
fragment.  Seems to be caused by by the badly nested <font> and <a> tags.

probably should get a 4xp keyword as this is not a problem in ie or ns4.

Comment 5

[Jesse Ruderman]

[e-mail], can you file that as a separate bug (but cross-
reference the two bugs)?  The testcase for this bug is valid HTML 3.2.  You're 
right, though, it is 4xp.

Comment 6

[Stephen Ostermiller]

Item that I reported with badly balanced <font> <a> tags has been filed as bug
64536.

Comment 7

[Jacek Piskozub]

This one looks closely related to (top100, mostfreq) bug 64622

Comment 8

[Tim Powell]

This bug still occurs in Mozilla 2001-01-16-04 WinNT Eng after bug 64622 was fixed.

In the Google example it does select the link for http://directory.google.com
after the 5th tab (press enter to verify this), but it does not mark the focus.
It seems to split the URL into two parts. The HTML that is failing is this:

<a href="http://directory.google.com"> <font color=#006600><b>Google Web
Directory</b></font></a>

The extra space seems to be the problem.

Strangely, in the www.cs.princeton.edu example, I can't tab to the bottom two
links. I can tab down to the one that starts with SPIM and then no more. The
SPIM link spans two lines, so that might be the problem....

Comment 9

[Tim Powell]

I should have looked at the bug summary... more analysis shows that this bug is
caused by the code:

<font size=-1><a href="http://directory.google.com"> <font
color=#006600><b>Google Web Directory</b></font></a></font>.

I'll attach a testcase. Each new font tag inside the font and anchor tags
generates another link.

Comment 10

[Tim Powell]

Attachment: testcase showing that HTML of font, a, font causes multiple links

Comment 11

[saari (gone)]

Yeah, this is a parser bug since the tabbing code will just view this as
multiple links (as it should given that is the DOM model that it is fed)

Comment 12

[Aaron Leventhal]

Attachment: Patch - an easy fix (changed it so we don't stop on frames of 0 width)

Comment 13

[Jesse Ruderman]

I don't think that patch will fix the first testcase (although it probably will 
fix Google).  That patch might also have negative effects if there's any other 
reason a focusable object had zero width.

Comment 14

[Aaron Leventhal]

What does that first testcase have to do with the original bug?
Testcase #1 doesn't show a bug with the focus disappearing, which was what this
bug orginally was. On my system testcase #1 shows a different bug - one link
being treated as two.

Also, what negative effects? When a frame has 0 width, it has no content and is
thus invisible on the screen. It shouldn't be focusable with the keyboard then.
How would a user know it was even there, or had focus? From a practical view, I
can think of no cases where a content-less link should get focus by keyboarding
to it.

Comment 15

[Aaron Leventhal]

Hmmm ... I definitely think there was a mistake here of having 2 different bugs
filed together.

Bug #1 - focus disappearing when it goes to contentless focusable node
Bug #2 - links being split in certain situations

Comment 16

[Aaron Leventhal]

Attachment: Patch #2 - whitespace fixed for Brendan

Comment 17

[Aaron Leventhal]

Attachment: Patch #3 against tip

Comment 18

[Brendan Eich [:brendan]]

aaron's patch #3 looks good to me, FWIW.

/be

Comment 19

[Jesse Ruderman]

>Bug #1 - focus disappearing when it goes to contentless focusable node
>Bug #2 - links being split in certain situations (parser problems)

I think this bug is really about #2.  That's what's happening on Google and on 
each of the testcases.  #1 also happens on Google *because* of #2, but so do 
plenty of other problems that have nothing to do with focus (drbrain's links 
panel probably shows the link twice, a program that reads the page out loud and 
indicates links would get confused, etc.)

Please file another bug for skipping over zero-width nodes when focusing.  This 
bug has already been cross-referenced with other bugs as the parser problem, so 
changing it to the workaround for Google would cause confusion.  (I still think 
the workaround sounds risky, btw.  Is width==0 really the same 
as "contentless"?)

Comment 20

[saari (gone)]

A width of zero really isn't the same thing as contentless. But tabbing to it
would definitely produce what looked like a lost tab press to the user. I don't
know what the right thing is here, if we should tab to logically invisible
content or not. Aaron, you're probably the best person to make that call, since
it is sort of an accessibility thing. Anyone know what IE does?

If you stick with this check, you should ad a check for zero height as well.

Comment 21

[bsharma]

updated qa contact.

Comment 22

[Asa Dotzler [:asa]]

Are you still shooting for 0.9 on this? If so please email [e-mail]
with a status on you progress. If not please retarget against a later Milestone.
Thanks.

Comment 23

[chris hofmann]

> [e-mail]

Comment 24

[Aaron Leventhal]

It turns out this is an HTML parsing bug, It sounds like people don't want my 
fix that uses zero-width frame check to see if a frame is worth tabbing to.
This bug should be assigned to someone who knows about parsing.

Comment 25

[Brendan Eich [:brendan]]

aaronl, please clear Target Milestone and reassign -- don't abuse mozilla1.0.1
yet (it's less meaningful than Future, but you don't really mean Future here,
you just need to reassign to harishd).

/be

Comment 26

[Tim Powell]

Worksforme (it appears to be fixed) in the 2nd testcase with 2001042504 WinNT.
Perhaps some parser problem was fixed?

Comment 27

[Aaron Leventhal]

This bug appears to have been fixed.

Comment 28

[bsharma]

Verified on
build: 2001-05-03-04
Platform: WinNT

In first testcase (attachment) after I press the tab 3nd time the focus is lost 
for couple of keystrokes of tab key and then come back at the text box.

In second testcase (attahment) same thing happens.

Comment 29

[Aaron Leventhal]

When I take the first testcase, and turn the "bcd" into a normal link with no 
font changes, I get the same behavior.

Therefore, I think that's a general navigation/tabbing problem, not anything to 
do with this bug.

Comment 30

[Aaron Leventhal]

Attachment: Shows that this bug is fixed - any extra tabs are from bug 83566

Comment 31

[Aaron Leventhal]

Any extra tabs here have nothing to do with font changes. See attachment.

Comment 32

[bsharma]

Verified on 2001-08-20-Trunk on WinNt

On google.com, the focus is not lost after clicking tab 5 times.
The attached test case also loads fine.

Comment 33

[bsharma]

Verified on 2001-08-20-Trunk on WinNt

On google.com, the focus is not lost after clicking tab 5 times.
The attached test case also loads fine.