Closed
Bug 66597
Opened 24 years ago
Closed 22 years ago
tab should start from insertion point or beginning of selection
Categories
(Core :: DOM: UI Events & Focus Handling, enhancement, P3)
Core
DOM: UI Events & Focus Handling
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: jruderman, Assigned: aaronlev)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: [Hixie-P0] checked in)
Attachments
(2 files, 12 obsolete files)
494 bytes,
text/html
|
Details | |
54.16 KB,
patch
|
bryner
:
review+
alecf
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
Steps to reproduce: 1. Click on the text "Mozilla News" at the top of http://www.mozilla.org/. 2. Press tab. Result: the first link on the page is focused. Expected result: the first link under Mozilla News should become focused.
Updated•24 years ago
|
Status: NEW → ASSIGNED
OS: Windows 98 → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → Future
Reporter | ||
Comment 1•24 years ago
|
||
See also bug 23914, "Start tabbing navigation from first visible element, not top". I don't think these are mutually exclusive: we could say "if the insertion point isn't visible, start tabbing from the top of the page".
Updated•23 years ago
|
Keywords: helpwanted
Reporter | ||
Comment 2•23 years ago
|
||
This bug disagrees with part 7 of mpt's proposed solution to bug 31809.
Comment 3•23 years ago
|
||
Not sure what should happen, but IE works as Jesse describes. Nav behavior seems very counter-intuitive. adding access keyword. Could reassign this to bryner, who has taken on similar bugs of late.
Keywords: access
Target Milestone: Future → mozilla0.9
Comment 4•23 years ago
|
||
I'm moving this out, I've got bigger issues on my plate. Anyone else is welcome to tackle this..
Target Milestone: mozilla0.9 → Future
Comment 5•23 years ago
|
||
reassigning to aaronl for triage
Assignee: alecf → aaronl
Status: ASSIGNED → NEW
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 7•23 years ago
|
||
I actually know how to fix this. It's just a matter of turning on some of the same features used when the pref accessibility.browsewithcaret is turned on. However, I'm afraid of what affects this would have on everyone because it's a fairly major change for us, to link tab navigation with the current insertion point. I would need to do it when there aren't any major deadlines looming.
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 8•23 years ago
|
||
Another case that's likely to affect more users: 1. Load http://developer.netscape.com/docs/manuals/htmlguid/contents.htm. 2. Search the page for "wb". 3. Press tab. Result: the location bar is focused. Expected: The link "wbr" should be focused. (Should the selection also go away? I think it should, because once bug 28583 and bug 36848 are fixed, focusing a textbox with tab would have to clear the old selection. It would seem strange if tabbing to a link left the old selection but tabbing to a textbox cleared it. Cc mpt.)
Reporter | ||
Updated•23 years ago
|
Summary: tab while insertion point is in text focuses from beginning of document → tab should start from insertion point or beginning of selection
Comment 9•23 years ago
|
||
In my opinion: * clicking (and selecting) should place the caret, whether it is visible or not; * Tabbing/Shift+Tabbing should move the caret, as well as changing which item is focused; * Tabbing/Shift+Tabbing should clear the selection. Conflict with bug 31809 is avoided, as I discussed with bryner, by placing the caret at the end of the document when it is first loaded.
Assignee | ||
Comment 10•23 years ago
|
||
Fixes the reverse problem as well -- find text now moves from the point of last focus. Also fixes bug 120023 -- a keyboard shortcut was needed to toggle "browse with caret mode" on/off. Two keys are given here, F2 and Accel+shift+C. The redundancy is required when function keys are used as accelerators (see the keyboard FAQ http://www.mozilla.org/projects/ui/accessibility/mozkeyfaq.html).
Comment 12•23 years ago
|
||
Comment on attachment 65640 [details] [diff] [review] Tested -- works. Probably needs more testing before going in. r=bryner
Attachment #65640 -
Flags: review+
Assignee | ||
Comment 13•23 years ago
|
||
Needs more testing, but works better with mouse clicks in page, and cycling through the document forward or backward. Need to test with: http://www.mozilla.org/quality/browser/front-end/testcases/keyboard-nav/tabbing.html
Attachment #65640 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Whiteboard: looking for r=, sr= → needs testing
Assignee | ||
Comment 14•22 years ago
|
||
Attachment #65749 -
Attachment is obsolete: true
Assignee | ||
Comment 15•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #67705 -
Attachment is obsolete: true
Assignee | ||
Comment 16•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #68007 -
Attachment is obsolete: true
Assignee | ||
Comment 17•22 years ago
|
||
Attachment #68486 -
Attachment is obsolete: true
Comment 18•22 years ago
|
||
nsbeta1- per ADT triage team. Would be good to get this in, but it seems like we could ship without it.
Assignee | ||
Comment 19•22 years ago
|
||
This is crucial for accessibility. * We need it for caret browsing, which is a P1 in the accessibility PRD. http://www.mozilla.org/projects/ui/accessibility/access-prd.html * Being able to search for text to navigate through links is crucial for keyboard users. Can we unminus this please?
Comment 20•22 years ago
|
||
remove - for reconsideration of Aaron's comments
Comment 21•22 years ago
|
||
preliminary results using a test build [2/8] of aaronl's on win2k: a. after finding a string on a page, focus goes there, and tabbing follows [or, goes backwards when shift+tabbing] from that point. b. converse of (a): after clicking somewhere on a page, focus is there, and find fwd [or backword, if specified] follows from there. c. if the found string is part of a link, the following occurs: the found string is highlighted *and* the link itself will display the focus ring.
Comment 22•22 years ago
|
||
found something rather tricky to repro --if someone has a more reliable test case, but all means add it here... [again, this is still using aaronl's homebrew.] 1. load http://mozilla.org/ 2. mouse+click right before the "For..." in the Download Mozilla section --it's the beginning of the 2nd sentence there. 3. hit tab. results: the link "report bugs" gets focused. expected: the link "Mozilla at a Glance" should really get focus since it's the next focusable item after where i had clicked the pointer.
Assignee | ||
Comment 23•22 years ago
|
||
Attachment #68573 -
Attachment is obsolete: true
Comment 24•22 years ago
|
||
Marking nsbeta1+ due to caret browsing dependency. If this is intended to make MachV, shouldn't it be retargetted to this milestone or the next? BTW, where does this idea of an invisible caret on click in the content come from? IE6 seems to have no such concept, and only focuses the page; don't we want to be compatible in that regard?
Assignee | ||
Comment 25•22 years ago
|
||
Actually, we are doing what IE does. If you click in content, it does focus the page, but the next tab or shift+tab moves relative to where you clicked.
Target Milestone: mozilla1.2 → mozilla0.9.9
Reporter | ||
Comment 26•22 years ago
|
||
> c. if the found string is part of a link, the following occurs: the found string
> is highlighted *and* the link itself will display the focus ring.
Sweet! I was about to file a [p-lynx] and [p-links] bug asking for that
feature. One question, though: if you find the search string outside of a link,
does it remove focus from a previously focused link? I think it should, because
a user might hit Enter quickly before realizing that the text found wasn't in a
link. In lynx and links, finding text that isn't a link doesn't move focus,
which I think is confusing.
Comment 27•22 years ago
|
||
Aaron: that is *not* how IE6 works, it has no concept of an invisible caret in the page.
Comment 28•22 years ago
|
||
Whether or not it is implemented in terms of a caret, it is certainly the case that IE starts searching from the last click position. It makes very good UI sense to tab from the same point, and I am reliably told IE does this too. I see absolutely no value in the opposite behaviour.
Whiteboard: needs testing → [Hixie-P0] needs testing
Comment 29•22 years ago
|
||
My copy of IE6, version 6.0.2600.000, running on Win2K, does not start from the click, but rather from the beginning of the page. I don't know about UI sense for vision impaired people, but I doubt many user's models include the concept of such an invisible marker in the page. In many other cases of accessibility support we have tried to follow IE, since that is the behavior nearly all of our accessibility customers are familiar with, and will usually expect. Are they complaining about this particular IE behavior? Is this a bug in IE6? (note: 'invisible caret' is just my term for the concept of a place marker that must be inferred in the user model since it is not present in the UI.)
Assignee | ||
Comment 30•22 years ago
|
||
Peter, I'm running the same version of IE on Win2k. 1. Load www.mozilla.org, click in the text "Mozilla 0.9.8" 2. Press Tab 3. The link that gets focused is the next link after that text This has worked in every version of IE that I've ever checked. It's especially important that it work after find text.
Comment 31•22 years ago
|
||
Yeah, that's the page I was testing too, and I think I see what you mean: the click seems to implicitly select a table. I get the same results you describe, but the next link is the first link in that table. Try instead clicking "Developer Day", and you'll tab to the the same link. IE starts from the beginning of the table, regardless of where you click in the text. I agree that tabs must start from a selection, if one exists (as IE does), but clicking in the text is not a selection.
Assignee | ||
Comment 32•22 years ago
|
||
After looking and again and again, generally I'm still getting it to tab relative to where I click. Sometimes I'm getting intermittend results. It has to be a click in the text itself, not in the whitespace. Peter, I'll have to sit down with you next time I'm in the office to take a look. If we decide to tab relative to a visible selection, but not relative to the last click in content (not a selection according to Peter's definition), we would have to differentiate between the two in our code. Right now we get both from the same patch, because internally we set a collapsed selection when the user clicks in the content. I'm not sure why it would be worth it to differentiate, in fact I find it quite useful to be able to click in the content and tab from there, as did the original writer of this bug.
Comment 33•22 years ago
|
||
It isn't *my* definition. See MHIG, for example, pp286-293. While an insertion point is considered to be a zero-length selection on the Mac (don't have WinUIG handy), selections must always have a visual cue. Do you have some accessibility software running that adds this? I'm just trying default IE vs N6, no JAWS or anything. BTW, I'm not saying it isn't useful, just not apparent, and differs from IE6, at least on my box.
Assignee | ||
Comment 34•22 years ago
|
||
Attachment #68969 -
Attachment is obsolete: true
Comment 35•22 years ago
|
||
initial observations, using a 2/18 test build from aaronl [again, win2k/mozilla] are the same as in comment 21. however, i've found a regression: if i click somewhere in a page and then try to tab from there, focus begins at the top of the content, no where near where i had clicked. example [a la comment 22]: 1. load http://mozilla.org/ 2. mouse+click right before the "For..." in the Download Mozilla section --it's the beginning of the 2nd sentence there. 3. hit tab. results: the banner at the top of the page [an image link] gets the focus ring. expected: the link "Mozilla at a Glance" should really get focus since it's the next focusable item after where i had clicked the pointer. or, even the "report bugs" link that i had gotten w/the 2/8 test build would've been a grand improvement.
Comment 36•22 years ago
|
||
oh, btw: i still see the "regression" in comment 35 whether or not i have caret browsing on.
Comment 37•22 years ago
|
||
okay, got a more recent build from aaronl: preliminary tests are good. cases in comment 21 work fine *and* the test in comment 22 actually works as expected! tested with caret browsing on and off. [other than the caret-disappearing issue i've noted in http://bugzilla.mozilla.org/show_bug.cgi?id=120023#c8.]
Comment 38•22 years ago
|
||
regression: unable to cycle through all the frames [when caret browsing is either on or off] via tabbing links. :( 1. go to a page with frames, http://faqs.org/ or viewer test #9 2. hit tab to cycle thru the links of all the frames... results: when i tried this with viewer test #9, tabbing never got out of the inlined "frame1". when i tried this with http://faqs.org/ i was able to cycle thru all of the frames once...then the second time i cycled thru i got stuck in the left nav frame --tabbing just went thru the links there over and over, not jumping into the other frames.
Comment 39•22 years ago
|
||
I still don't understand why anyone would expect clicking in non-editable text to create an invisible caret, especially since this is not done in other shipping browsers. Is there a spec for this I don't know about? cc UE for input.
Comment 40•22 years ago
|
||
for disabled users, fixing this focus problem will be extremely helpful in text and node selection and for navigating the page in general. aaron is the resident expert on caret browsing, skeptics should seek him out for a demonstration. fyi, IE6 seems to focus to either the node preceding or following, based on how much time has lapsed between insertion and focus switch. for example, if you insert an invisible caret in a body of text and IMMEDIATELY hit [tab] it takes you to the next available node that follows. however, if you insert caret and wait about +/- 3 seconds before hitting tab, it takes you to any node that preceded the insertion point. not sure if *that* is part of accessibility guidelines (aaron?), but it might be worth our effort to get it right
Comment 41•22 years ago
|
||
I don't see any such delay behavior here. An invisible caret that fades away like the Cheshire Cat seems curiouser and curiouser. It is like we're talking about two different programs. Are you guys all using some non-default, caret-browsing mode of these browsers? I'm just talking about the out-of-box experience for typical users.
Comment 42•22 years ago
|
||
Aha! I was just able to reproduce this delay. On my machine, if I tab almost simultaneously with the click, say within a tenth of a second or so, focus goes to the following node rather than the first node in the page/table. This seems far too dependent on split-second timing, and to me it feels like a bug in IE6. Is there any utility or precedent for changing the result of two separate gestures based on such precise timing (and without any apparent feedback)? Is this a known, documented behavior that AT users are counting on? Do we need to reproduce it?
Comment 43•22 years ago
|
||
yeah you're right, it's more like 0.25 seconds than 3 seconds as mentioned previously. sorry, my perception of time must have been skewed - it's too early in the morning for me i am not sure if it's a bug or not, we should try to determine if it is in fact a reliable behavior for users. and perhaps aaron knows more about it (or can find out)
Assignee | ||
Comment 44•22 years ago
|
||
I didn't actually know about this delay before. I'll look into it a bit more.
Comment 45•22 years ago
|
||
using a test build from 2/20, preliminary tests look good: a. focus follows where last clicked w/mouse. b. focus follows where last successful find occurred. c. find continues [when 'wrap around' and 'backwards' are *not* selected] from last focused location. d. focus is maintained when switching between multiple browser windows --i tested with 2 for simplicity. tested (a)-(d) with caret browsing on and off, as well as with non-framed and framed content. side note, variation on (d), for tabbed browser UI: with caret browsing on i noticed that focus is maintains when switching btwn tabs, with some slight oddness. the caret does indeed indicate where focus is, but a focus ring does persist on the previously-focused item. when caret browsing is off, focus does seem to be remembered with tab switching, but i still get that sticky, previously-focused ring. will investigate more and add comments to bug 120148...
Reporter | ||
Comment 46•22 years ago
|
||
>c. find continues [when 'wrap around' and 'backwards' are *not* selected] from >last focused location. Does it *only* work when doing a forward find without wrapping? In the future, the wrapping checkbox may be replaced by a dialog saying "you have reached the end of the document, search again to continue from the beginning" (bug 100631). In that case, "wrap around" would be permanently enabled.
Comment 47•22 years ago
|
||
i tested Find with wrapping and search backwards turned on, and Find appears to work as expected --it will start from the last focused position: if search backwards is set, Find will search in reverse starting from the point of last focus. if wrapping is set, Find will start at the point of last focus and loop through the page. jesse, does that answer your question? or, do you have a specific case in mind that you're concerned about?
Assignee | ||
Comment 48•22 years ago
|
||
Attachment #69523 -
Attachment is obsolete: true
Assignee | ||
Comment 50•22 years ago
|
||
Attachment #71029 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Whiteboard: [Hixie-P0] needs testing → [Hixie-P0] seeking r=bryner
Reporter | ||
Comment 51•22 years ago
|
||
se: It wasn't clear from your previous comment whether find didn't work correctly with other options, or whether you just hadn't tested the other options. Thanks for clearing that up and for testing the other options.
Comment 52•22 years ago
|
||
prelim testing with 2/23 build looks good --ran the same tests as in comment 45 and comment 47.
Comment 53•22 years ago
|
||
so, i have a question re: tabindex. using the test page below, i've seen the following: a. load the page and start tabbing: tab does indeed follow the order denoted by the link numbers [as does shift+tab in reverse]. b. if i click the mouse before a link: let's say i click btwn "the" and " link 3" --hitting tab will focus link 3, subequent tab link 4, etc, as expected. c. if i click after a link: let's say *right after* "link 3" --hitting tab will focus link 5, rather than link 4. just want to know if (c) is expected behavior! [best to have caret browsing on to see where exactly you are :)] test courtesy of aaronl: http://hopey.mcom.com/tests/tabindex.html [will attach soon].
Comment 54•22 years ago
|
||
Assignee | ||
Comment 55•22 years ago
|
||
That's okay, in that case the cursor is lingering after the link, but the link didn't get focused. If the link had been focused, the tab order would have been respected. We'll see through end-user testing whether they want the link to get focused when they click there.
Assignee | ||
Comment 56•22 years ago
|
||
Attachment #71062 -
Attachment is obsolete: true
Assignee | ||
Comment 57•22 years ago
|
||
Attachment #71438 -
Attachment is obsolete: true
Comment 58•22 years ago
|
||
Comment on attachment 71559 [details] [diff] [review] Oops - someone else wanted Accel+Shift+B for a bookmark related command. Switching to Accel+Shift+K "Select with Keyboard" r=bryner
Attachment #71559 -
Flags: review+
Assignee | ||
Updated•22 years ago
|
Whiteboard: [Hixie-P0] seeking r=bryner → [Hixie-P0] seekingsr=
Comment 59•22 years ago
|
||
Aaron, do you have any results from looking into the delay (comment #44)?
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.0
Updated•22 years ago
|
Attachment #71559 -
Flags: superreview+
Comment 60•22 years ago
|
||
Comment on attachment 71559 [details] [diff] [review] Oops - someone else wanted Accel+Shift+B for a bookmark related command. Switching to Accel+Shift+K "Select with Keyboard" sr=alecf
Assignee | ||
Updated•22 years ago
|
Whiteboard: [Hixie-P0] seekingsr= → [Hixie-P0] tested, reviewed, seeking a=
Comment 61•22 years ago
|
||
Comment on attachment 71559 [details] [diff] [review] Oops - someone else wanted Accel+Shift+B for a bookmark related command. Switching to Accel+Shift+K "Select with Keyboard" a=asa (on behalf of drivers) for checkin to the _trunk_
Attachment #71559 -
Flags: approval+
Assignee | ||
Comment 62•22 years ago
|
||
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [Hixie-P0] tested, reviewed, seeking a= → [Hixie-P0] checked in
Comment 63•22 years ago
|
||
vrfy'd fixed using 2002.03.13 comm trunk bits on linux rh7.2, win2k and mac 10.1.3. ran the following tests, which passed: a. tab and shift+tab should work fine, going btwn focusable content. if caret mode is on, arrow keys will move a line at a time *relative* to the current caret position (as in the editor). but if caret mode is off, arrow keys will scroll the page, regardless where the focus (invisible caret) might be. b. placement via mouseclick: test tabbing and selection. c. placement via Find: test tabbing and selection. d. non-framed page. e. framed page. f. page with form elements. g. tab browser. h. TABINDEX test. i. other windows which should recognize caret browsing, although for this bug, insertion, selection and tabbing should work the same whether or not caret browsing is on: * message pane in mailnews 3pane * mail standalone g. sanity check make sure tabbing/navigation still works: * Prefs window * [shift]+ctrl+tab to cycle btwn frames/panes * [shift]+F6 to cycle btwn frames/panes
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 64•22 years ago
|
||
Caused regression: bug 131139, Right-clicking or dragging a link clears selection.
Comment 65•22 years ago
|
||
Also caused bug 130447, "Clicking on anchor goes to top of page, entering the URL directly doesn't". Anything we can do at review or testing time to protect against future regressions when changing this gnarly anchor code in the pres-shell? /be
Assignee | ||
Comment 66•22 years ago
|
||
We did a lot of testing before checking this in, but we simply didn't catch everything, although we tried.
Comment 67•22 years ago
|
||
One idea is to list the bug numbers that should be tested before changing the code. I've started using that approach in focus code to help keep my sanity. Cause a regression, add that bug number to the list in the comment :-)
Updated•5 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
•