280154 - Cannot arrow past first item in Glossary, Index, Search or Contents

Status: RESOLVED FIXED

(SeaMonkey :: Help Viewer, defect, P1)

Description

[Aaron Leventhal]

Steps:
1. Open help
2. Go to any of the tabs Glossary, Index, Search or Contents
3. If in search, typing something to get a list of matches
4. Tab to the list in the current panel
5. Even though focus is not visible, you are in the list (see bug 280153)
6. Try to down arrow twice

What happens:
Once the arrow key moves selection the first time, that triggers a document load
in content pane and sets focus there.
The next arrow key affects the content pane, instead of moving to the next list
item like it should.

Comment 1

[Aaron Leventhal]

This makes help unusable for non-mouse users.

Comment 2

[Jeff Walden (gone starting June 8)]

This will have to wait until bug 279506 is at least a ways down the track to
being fixed, but it looks like it should be doable without too much effort. 
Tentatively targetting this for 1.1 as it doesn't look too difficult to handle...

Comment 3

[Steffen Wilberg]

Targetting bugs which were targetted to Firefox1.1 before the move to
mozilla1.8beta2.

Comment 4

[Doron Rosenberg (IBM)]

How exactly can this be fixed? Seamonkey has the same issue.

Comment 5

[Doron Rosenberg (IBM)]

So neil on IRC figured why some focus and some don't - if we link to an anchor
(foo.xhtml#bar), we set focus, since:
<bz> doron: that's how anchors are implemented -- place focus on the anchor
target, and scroll to focus

So we would need to fix the way anchors work.

Comment 6

[Aaron Leventhal]

(In reply to comment #5)
> So we would need to fix the way anchors work.
I would be open to making links not get focus when we jump to a named anchor.

I also wonder if this would help:
document.commandDispatcher.suppressFocus = true;
(for the help pane)

Comment 7

[Doron Rosenberg (IBM)]

document.commandDispatcher.suppressFocus = true; didn't work

Comment 8

[Jeff Walden (gone starting June 8)]

My guess is the best bet is just to load the page and then refocus upon the
appropriate tree item.  Then there's no worry about some focusing and some not
-- they'll all get refocused.  I don't imagine this would be too difficult to
do, and I plan to do it probably over this weekend.

Comment 9

[Doron Rosenberg (IBM)]

That might cause some confusion (focus changing and all), but might be good
enough for now.

Comment 10

[Aaron Leventhal]

(In reply to comment #9)
> That might cause some confusion (focus changing and all), but might be good
> enough for now.

Yes, please try it. I'll test the patch to see what it does with the screen reader.

Comment 11

[Aaron Leventhal]

Attachment: Remove a line -- we don't need to set focus to the document in nsPresShell:GoToAnchor()

It's not actually true that we scroll to the anchor by focusing it. We scroll
to it by selecting the anchor (sometimes we collapse the selection depending on
layout.selectanchor.

The focus event on the document appears to be superfluous. I can't see any
desired behavior that regresses by removing that. For example, we still scroll
to the anchor, we still set selection and focus still goes to the document when
a URL with #foo is loaded.

Comment 12

[[e-mail]]

Comment on attachment 180092 [details] [diff] [review]
Remove a line -- we don't need to set focus to the document in nsPresShell:GoToAnchor()

Looks good to me.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> I can't see any desired behavior that regresses by removing that.

With that patch, if I click a link to an in-document anchor, we scroll to the
anchor but the focus outline remains on the link I clicked.  It's not "really"
focused, though (eg hitting tab after this doesn't behave as if it were
focused).  That seems pretty poor to me.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that shows that problem

Comment 15

[Aaron Leventhal]

Attachment: Keep focus in the document if we were focused in the document, otherwise don't touch the focus

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 180337 [details] [diff] [review]
Keep focus in the document if we were focused in the document, otherwise don't touch the focus

Make those asserts into if-checks, and sr=bzbarsky.  I'm not convinced that in
all embedding (or printing, or whatever) situations we have focus controllers
and the like.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 180337 [details] [diff] [review]
Keep focus in the document if we were focused in the document, otherwise don't touch the focus

a=asa

Comment 18

[Aaron Leventhal]

/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.830; previous revision: 3.829
done

Comment 19

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381