54406 - Can't tab past a link which contains a hard or soft line break

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[sairuh (rarely reading bugmail)]

spun off from bug 3593 --i'm not sure what the root cause of this problem, if
it's event handling, tables or what... it doesn't occur on all pages, but it
definitely happens on the Mozilla home page (but not, say, on
bugzilla.mozilla.org).

initially assigning to lake --lake, d'you know who should get this? found this
using 2000.09.26/27.xx opt comm bits [branch] on the 3 main platforms.

1. go to the above url.
2. click somewhere in the content to bring focus (but not a link).
3. hit the Tab key to navigate between links.

results: focus (denoted by the hatched outline and url in the statusbar) remains
on the first link, "The Mozilla Organization" in the upper left of the page.

expected: should be able to cycle through the links on the page.

Comment 1

[sairuh (rarely reading bugmail)]

hm, none of the mozilla.org pages which have the left grey column allow tabbing
btwn links. after a glance at the source (comparing the mozilla web page with,
say, the bugzilla main page), TD tags in www.mozilla,org have NOWRAP specified,
but am unsure if that's really the cause...

Comment 2

[Lakespur Roca]

I'm not sure who should get this one but McAfee might. This is not the only
problem with tabbing and focus. I have noticed on a number of non Mozilla pages
that some times it takes 10 tabs to get the next thing to have focus. Could
these be related?

Comment 3

[sairuh (rarely reading bugmail)]

not sure...although, conversely, after i tab through over a dozen links/elements
in a page, the tabbing just stops. (another bug, i presume?)

anyhow, i whipped up a couple pages with and without NOWRAP specified for TF
tags --nope, that ain't the problem (both simple cases worked).

Comment 4

[Chris McAfee]

WinNT:  Frameset problem?  I can tab to links here:
  http://ftp.mozilla.org/pub/mozilla/nightly/latest/
ok, but yes I get stuck on the first URL at
  http://www.mozilla.org

I also get stuck on some URL's on other pages.

Comment 5

[Chris McAfee]

Attachment: reduced test case of http://www.mozilla.org

Comment 6

[Chris McAfee]

over to rods for a look.  Attached a reduced test case, tabbing
gets stuck on the first link.  Win32 & Linux.

Comment 7

[Chris McAfee]

Attachment: further reduced test case.

Comment 8

[rods (gone)]

Attachment: further reduced with no tables

Comment 9

[rods (gone)]

I doesn't matter if the second lement to be tabbed to is a form control or a 
link. it does just get stuck on the fist item. It seems to be a bug in the 
traversal object. It keeps finding the first link. reassigning

Comment 10

[John Morrison]

See also bug 51680, which is very close to the same test case. This does appear
to be a more common bug than I originally thought, and I hit this on quite
a few web pages (stuck while tabbing).

Adding rtm for consideration. Note: this may be joki's bug (he says as much
on bug 51680).

Comment 11

[saari (gone)]

Rod, did you walk through the traversal? Everytime I've seen this, the frame tree 
is incorrect, where a child is also a sibling. That error in the frame tree will 
muck up the traversal object something fierce.

If that is not the case, this is probably a dup of 51680

Comment 12

[sairuh (rarely reading bugmail)]

adding rods back so that he can respond to saari's question above.

Comment 13

[saari (gone)]

The problem is the <BR> tag in the middle of the anchor.

Comment 14

[saari (gone)]

Generally, I think the problem is a line break in the middle of any tabbable
thing will confuse it. I might not normally want this plussed, but it happens on
mozilla.org :-(

Comment 15

[Chris McAfee]

ack!  Good catch saari.

Comment 16

[Peter Trudelle]

rtm-/future, can workaround by selecting after the broken link.

Comment 17

[Matthew T (active 1999-2002)]

I wonder how I can select anything after the <BR>ed link if I'm someone who can't 
use a mouse ...

Comment 18

[Jesse Ruderman]

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

Comment 19

[Jesse Ruderman]

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

Comment 20

[Jesse Ruderman]

Attachment: another test case

Comment 21

[Jesse Ruderman]

Probably enough testcases for the "testcase" keyword :)  All/all.

Comment 22

[Jesse Ruderman]

Happens for links split automatically and for links containing <br>.  Shift-tab 
doesn't seem to be affected by this bug.

Comment 23

[Casey Perkins]

One other minor thing which is related to this bug, but an enhancement:
In IE and Netscape 4, the first time you press Tab the focus is placed in the
Location area. The next tab selects the first link or form element on the page.
It would be helpful if Mozilla would support this (or some other way of keyboard
navigating to the Location area, like Opera's F6), since it's a behavior many
browser users have come to expect.

Comment 24

[Arnoud Berendsen]

I definately agree with the above, not placing focus on the Location bar when
TAB is pressed the first time is definately annoying, and I think (know, even) a
lot of people will agree on that. To me, this is even more important than being
able to browse through the links on a page with TAB! It would definately be a
step back from NS4 if Moz didn't support this behaviour anymore!

Comment 25

[Jesse Ruderman]

I always thought that was a NS4 bug: pressing tab from the username field on 
http://www.itsajob.com/ would jump to the location bar, forcing me to press tab 
a whole bunch of times before I could type my password in.  Anyway, that's 
really bug 31809.

Comment 26

[Gervase Markham [:gerv]]

Nominating relnote-devel, because AIUI this is something for page authors to 
avoid. If I'm wrong, please correct to relnote-user.

Gerv

Comment 27

[timeless]

relnote-user: If while tabbing from link to link you can not reach the end, 
please try Shift-tab which does not seem to be affected by this bug.

Comment 28

[Jesse Ruderman]

This wouldn't be very easy for page authors to work around -- they would 
basically have to eliminate spaces from links or replace them with  .  
Relnoting doesn't legally shift responsibility for the workaround to page 
authors, does it?

I have a vague idea of how to work around this bug and bug 29086 with a 
bookmarklet.  Would that be useful at all, or do you think keyboard-only people 
would rather use mousekeys to 'click' on the next element?

Timeless: shift-tab moves backward in the tab order, and tabbing gets stuck 
again next time the wrapped link gets focus :(

Comment 29

[timeless]

Zapping relnote-devel. Relnote user, no good workaround, erm So sue me.

[e-mail]:
Can you alter your links sidebar to have the following saving graces:
a) some way to keyboard to it
b) pressing errors keys would NOT change urls
c) pressing space would set focus to the currently highlighted link
d) pressing enter would activate the highlighted link

Also, can you detect links that have onEvents? if so it might be useful to have 
minor trees:
<link>
*<onclick>{display of event}
*<onmouseover>{display of event}
...

Note: I know that the links thing would not normally match tab order because it 
does not handle form items, but my hope is that the <space> support would 
enable users to land near the form.

mpt: I'm expecting you to object to my choice of keybindings. comments 
solicited.
se: you filed this bug, would you use the links sidebar if the relnote 
described how to use it to work around this problem?

My suggestion: we might be able to make a crutch out of a 3rd party add on.

Comment 30

[Matthew T (active 1999-2002)]

No objections to those keybindings, if by (c) you mean `pressing space would set 
focus to the currently highlighted link *in the main content*' (otherwise it 
seems nugatory).

But to be honest, I don't think anyone would use this sidebar panel as a 
workaround for this bug. Even people who can't use mice at all wouldn't use it -- 
there are so many other accessibility blocker bugs open that it's going to be 
practically impossible for people who can't use mice to use Netscape 6.0 anyway.

Comment 31

[Eric Hodel]

a) some way to keyboard to it
If there is a way to keyboard to any sidebar panel I don't know of it, bug?

b) pressing errors keys would NOT change urls
c) pressing space would set focus to the currently highlighted link
d) pressing enter would activate the highlighted link

These last three require me to fool around with XUL elements I haven't yet
learned (the main reason I wrote the panel).  Just yesterday I figured out how
to get tooltips to display.  Maybe I'll work on keybindings next, but I was
planning on maybe <tree>.  Also the panel should support display of visited links.

I'm not certain if I'll be able to handle onclick or onmouseover, as I need to
use onclick to get the link to load in the browser window.

In short, I'll see what I can do.

Comment 32

[Matthew T (active 1999-2002)]

Keyboard access to the sidebar is bug 30864 and bug 48251 (which are examples of 
non-`rtm+'-ed accessibility blocker bugs).

Eric, using <tree> to show links would be a good way of preventing your panel 
from having the same problem as this bug itself, but it shouldn't be a long-term 
solution as it would unnecessarily crop the entries.

Comment 33

[timeless]

mpt yes by (c) I meant `pressing space would set focus to the currently 
highlighted link *in the main content*'

Yes a tree would solve most of b-d
as for the things after d, I presume that the links object gives you the enter 
link item ie <a href="blah" onclick="bleh" onmouseover="bloh" 
onmousedown="blih"> in which case what i would like is:

blah
.{onclick} bleh
.{onmouseover} bloh
.{onmousedown} blih

where everything but . is literal, and oncommand would go to the non {}'d text; 
. represents a child.

saari: i'm sorry to scribble on your bug.

Comment 34

[saari (gone)]

Targeting Mozilla 0.9

Comment 35

[Jesse Ruderman]

bookmarklet hack for release notes:
http://www.cs.hmc.edu/~jruderma/mozilla/override-tab.html

Comment 36

[James Lariviere]

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

Comment 37

[saari (gone)]

This is very annoying and limits accessiblity. Target Mozilla 0.8

Comment 38

[Aaron Leventhal]

This <br> in a link problem happens quite often.
For example LXR & yahoo.com. This bug has become a major issue for me.

Comment 39

[saari (gone)]

I am painfully aware of the frequency of this problem.

Comment 40

[Chris McAfee]

nsbeta1

Comment 41

[saari (gone)]

Attachment: patch from Aaron that fixes this problem!

Comment 42

[Brian Ryner (not reading)]

r=bryner

Comment 43

[Jesse Ruderman]

Does the patch fix bug 51680 as well?

Comment 44

[saari (gone)]

It should fix 51680 too

Comment 45

[Angela Butler]

Adding branch accept to status whiteboard.  Chris, please check into the branch 
ASAP. Thx
.Angela...

Comment 46

[Chris Waterson]

sr=waterson

Comment 47

[saari (gone)]

Fixed

Comment 48

[Loco]

Still broken in Mac OS 01-18-15, but fixed in Win 98 01-18-21.

REOPENING.

Comment 49

[John Morrison]

If saari checked in the fix at 5:30pm on 1/18, how, pray tell, was that fix
supposed to appear in the 3pm 1/18 build for Mac.

Marking FIXED, and we can have another go at this ...

Comment 50

[Loco]

I'm a moron, that's how.  See bug 60787.  Should ammend to "Update mozilla before 
its possible."  My bad.:)

Comment 51

[Loco]

Ok, Hope this makes up for it.  Works wonderfully in Mac OS build 01-19-12, as 
expected by reasonable people.

VERIFIED.

Comment 52

[sairuh (rarely reading bugmail)]

...and like a charm with a recent linux mozilla [debug] build. coolio!

Comment 53

[sairuh (rarely reading bugmail)]

vrfy fixed for the branch:

winNT 2001.01.22.19-mtest
linux rh 6.2 2001.01.22.18-mtest
mac os 9.0 2001.01.22.17-mtest