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.

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".

This bug disagrees with part 7 of mpt's proposed solution to bug 31809.

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.

I'm moving this out, I've got bigger issues on my plate. Anyone else is welcome to tackle this..

reassigning to aaronl for triage

->---

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.

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.)

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.

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).

Bryner, can you review this?

Comment on attachment 65640 [details] [diff] [review] Tested -- works. Probably needs more testing before going in. r=bryner

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

nsbeta1- per ADT triage team. Would be good to get this in, but it seems like we could ship without it.

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?

remove - for reconsideration of Aaron's comments

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.

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.

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?

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.

> 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.

Aaron: that is *not* how IE6 works, it has no concept of an invisible caret in the page.

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.

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.)

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.

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.

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.

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.

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.

oh, btw: i still see the "regression" in comment 35 whether or not i have caret browsing on.

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.]

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.

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.

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

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.

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?

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)

I didn't actually know about this delay before. I'll look into it a bit more.

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...

>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.

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?

Seeking r=

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.

prelim testing with 2/23 build looks good --ran the same tests as in comment 45 and comment 47.

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].

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.

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

Aaron, do you have any results from looking into the delay (comment #44)?

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

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_

fix checked in

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

Caused regression: bug 131139, Right-clicking or dragging a link clears selection.

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

We did a lot of testing before checking this in, but we simply didn't catch everything, although we tried.

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 :-)