66597 - tab should start from insertion point or beginning of selection

Status: VERIFIED FIXED

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

Description

[Jesse Ruderman]

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.

Comment 1

[Jesse Ruderman]

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

Comment 2

[Jesse Ruderman]

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

Comment 3

[Peter Trudelle]

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.

Comment 4

[Alec Flett]

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

Comment 5

[Peter Trudelle]

reassigning to aaronl for triage

Comment 6

[Peter Trudelle]

->---

Comment 7

[Aaron Leventhal]

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.

Comment 8

[Jesse Ruderman]

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

Comment 9

[Matthew T (active 1999-2002)]

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.

Comment 10

[Aaron Leventhal]

Attachment: Tested -- works. Probably needs more testing before going in.

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 11

[Aaron Leventhal]

Bryner, can you review this?

Comment 12

[Brian Ryner (not reading)]

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

r=bryner

Comment 13

[Aaron Leventhal]

Attachment: More changes in esm::ShiftFocus

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

Comment 14

[Aaron Leventhal]

Attachment: Many more changes -- testing done, more needed

Comment 15

[Aaron Leventhal]

Attachment: Now also fixes bug 103284

Comment 16

[Aaron Leventhal]

Attachment: Passes my tests -- on to Sarah Liberman

Comment 17

[Aaron Leventhal]

Attachment: Fixes one more case, where selection is a end of a link after find text

Comment 18

[Peter Trudelle]

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

Comment 19

[Aaron Leventhal]

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

[Kathleen :Brade]

remove - for reconsideration of Aaron's comments

Comment 21

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

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.

Comment 23

[Aaron Leventhal]

Attachment: Still neds work

Comment 24

[Peter Trudelle]

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?

Comment 25

[Aaron Leventhal]

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.

Comment 26

[Jesse Ruderman]

> 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

[Peter Trudelle]

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

Comment 28

[Hixie (not reading bugmail)]

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.

Comment 29

[Peter Trudelle]

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

Comment 30

[Aaron Leventhal]

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

[Peter Trudelle]

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.

Comment 32

[Aaron Leventhal]

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

[Peter Trudelle]

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.  

Comment 34

[Aaron Leventhal]

Attachment: Still a problem with remembering the focus of the last window, did that work before?

Comment 35

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

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

Comment 37

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

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

[Peter Trudelle]

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

[marlon bishop]

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

[Peter Trudelle]

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

[Peter Trudelle]

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

[marlon bishop]

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)

Comment 44

[Aaron Leventhal]

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

Comment 45

[sairuh (rarely reading bugmail)]

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

Comment 46

[Jesse Ruderman]

>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

[sairuh (rarely reading bugmail)]

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?

Comment 48

[Aaron Leventhal]

Attachment: Changes F2 caret toggle to INSERT, other than that the same as what was QA'd extensively by Sarah Liberman, could not find any glitches

Comment 49

[Aaron Leventhal]

Attachment: Fixes crash that Sarah found, takes care of issues bryner pointed out

Seeking r=

Comment 50

[Aaron Leventhal]

Attachment: Fixes regression in tabindex support that had been overlooked

Comment 51

[Jesse Ruderman]

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

[sairuh (rarely reading bugmail)]

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

Comment 53

[sairuh (rarely reading bugmail)]

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

[sairuh (rarely reading bugmail)]

Attachment: tabindex test page

Comment 55

[Aaron Leventhal]

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 56

[Aaron Leventhal]

Attachment: Same patch as before, changes toggle keystroke to Accel+Shift+B

Comment 57

[Aaron Leventhal]

Attachment: Oops - someone else wanted Accel+Shift+B for a bookmark related command. Switching to Accel+Shift+K "Select with Keyboard"

Comment 58

[Brian Ryner (not reading)]

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

Comment 59

[Peter Trudelle]

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

Comment 60

[Alec Flett]

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 61

[Asa Dotzler [:asa]]

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_

Comment 62

[Aaron Leventhal]

fix checked in

Comment 63

[sairuh (rarely reading bugmail)]

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

Comment 64

[Jesse Ruderman]

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

Comment 65

[Brendan Eich [:brendan]]

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

Comment 66

[Aaron Leventhal]

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

Comment 67

[saari (gone)]

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