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)
Core
DOM: UI Events & Focus Handling
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.
Reporter | ||
Comment 1•24 years ago
|
||
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•24 years ago
|
||
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?
Reporter | ||
Comment 3•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Comment 6•24 years ago
|
||
over to rods for a look. Attached a reduced test case, tabbing gets stuck on the first link. Win32 & Linux.
Assignee: lake → rods
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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
Assignee | ||
Comment 11•24 years ago
|
||
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
Reporter | ||
Comment 12•24 years ago
|
||
adding rods back so that he can respond to saari's question above.
Assignee | ||
Comment 13•24 years ago
|
||
The problem is the <BR> tag in the middle of the anchor.
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•24 years ago
|
||
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•24 years ago
|
||
ack! Good catch saari.
Comment 16•24 years ago
|
||
rtm-/future, can workaround by selecting after the broken link.
Whiteboard: [rtm-]
Target Milestone: --- → Future
Reporter | ||
Updated•24 years ago
|
Keywords: relnoteRTM
Comment 17•24 years ago
|
||
I wonder how I can select anything after the <BR>ed link if I'm someone who can't use a mouse ...
Keywords: access
Comment 18•24 years ago
|
||
*** Bug 51680 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
*** Bug 51042 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Comment 21•24 years ago
|
||
Probably enough testcases for the "testcase" keyword :) All/all.
Keywords: testcase
OS: Linux → All
Comment 22•24 years ago
|
||
Happens for links split automatically and for links containing <br>. Shift-tab doesn't seem to be affected by this bug.
Comment 23•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Comment 27•24 years ago
|
||
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
Comment 28•24 years ago
|
||
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•24 years ago
|
||
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
Comment 30•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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 35•24 years ago
|
||
bookmarklet hack for release notes: http://www.cs.hmc.edu/~jruderma/mozilla/override-tab.html
Comment 36•24 years ago
|
||
*** Bug 51863 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 37•24 years ago
|
||
This is very annoying and limits accessiblity. Target Mozilla 0.8
Target Milestone: mozilla0.9 → mozilla0.8
Comment 38•24 years ago
|
||
This <br> in a link problem happens quite often. For example LXR & yahoo.com. This bug has become a major issue for me.
Assignee | ||
Comment 39•24 years ago
|
||
I am painfully aware of the frequency of this problem.
Updated•24 years ago
|
Summary: unable to tab btwn links in www.mozilla.org → Can't tab past a link which contains a hard or soft line break
Assignee | ||
Comment 41•24 years ago
|
||
Comment 42•24 years ago
|
||
r=bryner
Comment 43•24 years ago
|
||
Does the patch fix bug 51680 as well?
Assignee | ||
Comment 44•24 years ago
|
||
It should fix 51680 too
Comment 45•24 years ago
|
||
Adding branch accept to status whiteboard. Chris, please check into the branch ASAP. Thx .Angela...
Whiteboard: relnote-user → [branch accept] relnote-user
Comment 46•24 years ago
|
||
sr=waterson
Assignee | ||
Comment 47•24 years ago
|
||
Fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 48•24 years ago
|
||
Still broken in Mac OS 01-18-15, but fixed in Win 98 01-18-21. REOPENING.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 49•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → FIXED
Comment 50•24 years ago
|
||
I'm a moron, that's how. See bug 60787. Should ammend to "Update mozilla before its possible." My bad.:)
Comment 51•24 years ago
|
||
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
Reporter | ||
Comment 52•24 years ago
|
||
...and like a charm with a recent linux mozilla [debug] build. coolio!
Reporter | ||
Comment 53•24 years ago
|
||
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
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
You need to log in
before you can comment on or make changes to this bug.
Description
•