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)

enhancement

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+
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.
Status: NEW → ASSIGNED
OS: Windows 98 → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → Future
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.
Keywords: access
Target Milestone: Future → mozilla0.9
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
reassigning to aaronl for triage
Assignee: alecf → aaronl
Status: ASSIGNED → NEW
->---
Target Milestone: Future → ---
Severity: normal → enhancement
Keywords: helpwanted
Target Milestone: --- → mozilla1.2
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.
Status: NEW → ASSIGNED
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.)
Summary: tab while insertion point is in text focuses from beginning of document → tab should start from insertion point or beginning of selection
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.
Depends on: 56472
Blocks: 103284
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?
Whiteboard: looking for r=, sr=
Comment on attachment 65640 [details] [diff] [review]
Tested -- works. Probably needs more testing before going in.

r=bryner
Attachment #65640 - Flags: review+
Attached patch More changes in esm::ShiftFocus (obsolete) — Splinter Review
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
Whiteboard: looking for r=, sr= → needs testing
Attachment #65749 - Attachment is obsolete: true
Attached patch Now also fixes bug 103284 (obsolete) — Splinter Review
Attachment #67705 - Attachment is obsolete: true
Attachment #68007 - Attachment is obsolete: true
Attachment #68486 - Attachment is obsolete: true
nsbeta1- per ADT triage team.  Would be good to get this in, but it seems like
we could ship without it.
Keywords: nsbeta1nsbeta1-
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
Keywords: nsbeta1-nsbeta1
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.
Attached patch Still neds work (obsolete) — Splinter Review
Attachment #68573 - Attachment is obsolete: true
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?
Keywords: nsbeta1nsbeta1+
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
> 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.
Whiteboard: needs testing → [Hixie-P0] needs testing
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=
Attachment #70855 - Attachment is obsolete: true
Attachment #71029 - Attachment is obsolete: true
Whiteboard: [Hixie-P0] needs testing → [Hixie-P0] seeking r=bryner
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.
Attachment #71062 - Attachment is obsolete: true
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+
Whiteboard: [Hixie-P0] seeking r=bryner → [Hixie-P0] seekingsr=
Aaron, do you have any results from looking into the delay (comment #44)?
Target Milestone: mozilla0.9.9 → mozilla1.0
Attachment #71559 - Flags: superreview+
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
Whiteboard: [Hixie-P0] seekingsr= → [Hixie-P0] tested, reviewed, seeking a=
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+
Blocks: 128741
fix checked in
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [Hixie-P0] tested, reviewed, seeking a= → [Hixie-P0] 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
Status: RESOLVED → VERIFIED
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 :-)
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.