Closed Bug 54406 Opened 24 years ago Closed 24 years ago

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

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: bugzilla, Assigned: saari)

References

()

Details

(Keywords: access, testcase, Whiteboard: [branch accept] relnote-user)

Attachments

(5 files)

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.
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...
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?
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).
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.
over to rods for a look.  Attached a reduced test case, tabbing
gets stuck on the first link.  Win32 & Linux.
Assignee: lake → rods
Attached file further reduced test case. (deleted) —
Attached file further reduced with no tables (deleted) —
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
Assignee: rods → saari
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).
Keywords: rtm
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
adding rods back so that he can respond to saari's question above.
The problem is the <BR> tag in the middle of the anchor.
Status: NEW → ASSIGNED
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 :-(
ack!  Good catch saari.
rtm-/future, can workaround by selecting after the broken link.
Whiteboard: [rtm-]
Target Milestone: --- → Future
Keywords: relnoteRTM
I wonder how I can select anything after the <BR>ed link if I'm someone who can't 
use a mouse ...
Keywords: access
*** Bug 51680 has been marked as a duplicate of this bug. ***
*** Bug 51042 has been marked as a duplicate of this bug. ***
Attached file another test case (deleted) —
Probably enough testcases for the "testcase" keyword :)  All/all.
Keywords: testcase
OS: Linux → All
Happens for links split automatically and for links containing <br>.  Shift-tab 
doesn't seem to be affected by this bug.
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.
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!
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.
Nominating relnote-devel, because AIUI this is something for page authors to 
avoid. If I'm wrong, please correct to relnote-user.

Gerv
Whiteboard: [rtm-] → [rtm-] relnote-devel
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.
Whiteboard: [rtm-] relnote-devel → [rtm-] relnote-devel relnote-user
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 &nbsp;.  
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 :(
Zapping relnote-devel. Relnote user, no good workaround, erm So sue me.

drbrain@segment7.net:
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.
Whiteboard: [rtm-] relnote-devel relnote-user → [rtm-] relnote-user
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.
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.
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.
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.
Targeting Mozilla 0.9
Target Milestone: Future → mozilla0.9
bookmarklet hack for release notes:
http://www.cs.hmc.edu/~jruderma/mozilla/override-tab.html
*** Bug 51863 has been marked as a duplicate of this bug. ***
This is very annoying and limits accessiblity. Target Mozilla 0.8
Target Milestone: mozilla0.9 → mozilla0.8
This <br> in a link problem happens quite often.
For example LXR & yahoo.com. This bug has become a major issue for me.
Blocks: 20159
I am painfully aware of the frequency of this problem.
Summary: unable to tab btwn links in www.mozilla.org → Can't tab past a link which contains a hard or soft line break
nsbeta1
Keywords: nsbeta1
Keywords: rtmapproval, patch, review
Whiteboard: [rtm-] relnote-user → relnote-user
r=bryner
Does the patch fix bug 51680 as well?
It should fix 51680 too
Adding branch accept to status whiteboard.  Chris, please check into the branch 
ASAP. Thx
.Angela...
Whiteboard: relnote-user → [branch accept] relnote-user
sr=waterson
Fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Still broken in Mac OS 01-18-15, but fixed in Win 98 01-18-21.

REOPENING.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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 ...
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
I'm a moron, that's how.  See bug 60787.  Should ammend to "Update mozilla before 
its possible."  My bad.:)
Ok, Hope this makes up for it.  Works wonderfully in Mac OS build 01-19-12, as 
expected by reasonable people.

VERIFIED.
Status: RESOLVED → VERIFIED
...and like a charm with a recent linux mozilla [debug] build. coolio!
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
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: