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

RESOLVED FIXED in mozilla1.8beta2

Status

P1
major
RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: aaronlev, Assigned: aaronlev)

Tracking

(Blocks: 1 bug, {access, helpwanted, sec508})

unspecified
mozilla1.8beta2
access, helpwanted, sec508
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

14 years ago
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.
(Assignee)

Comment 1

14 years ago
This makes help unusable for non-mouse users.
Flags: blocking-aviary1.1?
(Assignee)

Updated

14 years ago
Keywords: helpwanted
Priority: -- → P1
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...
Status: NEW → ASSIGNED
Hardware: PC → All
Target Milestone: --- → Firefox1.1

Updated

14 years ago
Component: Help Viewer → Help Viewer
Flags: blocking-aviary1.1?
Product: Firefox → Toolkit
Target Milestone: Firefox1.1 → ---

Comment 3

14 years ago
Targetting bugs which were targetted to Firefox1.1 before the move to
mozilla1.8beta2.
Target Milestone: --- → mozilla1.8beta2
How exactly can this be fixed? Seamonkey has the same issue.
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.
(Assignee)

Comment 6

14 years ago
(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)

document.commandDispatcher.suppressFocus = true; didn't work
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.
That might cause some confusion (focus changing and all), but might be good
enough for now.
(Assignee)

Comment 10

14 years ago
(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.
(Assignee)

Comment 11

14 years ago
Created attachment 180092 [details] [diff] [review]
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.
Attachment #180092 - Flags: second-review?(bzbarsky)
Attachment #180092 - Flags: first-review?(neil.parkwaycc.co.uk)
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.
Attachment #180092 - Flags: first-review?(neil.parkwaycc.co.uk) → first-review+
> 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.
Created attachment 180142 [details]
Testcase that shows that problem
(Assignee)

Comment 15

14 years ago
Created attachment 180337 [details] [diff] [review]
Keep focus in the document if we were focused in the document, otherwise don't touch the focus
Assignee: jwalden+fxhelp → aaronleventhal
Attachment #180337 - Flags: second-review?(bzbarsky)
Attachment #180092 - Flags: second-review?(bzbarsky) → second-review-
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.
Attachment #180337 - Flags: second-review?(bzbarsky) → second-review+
(Assignee)

Updated

14 years ago
Attachment #180337 - Flags: approval1.8b2?
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
Attachment #180337 - Flags: approval1.8b2? → approval1.8b2+
(Assignee)

Comment 18

14 years ago
/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.830; previous revision: 3.829
done
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

12 years ago
Flags: in-testsuite?
Product: Toolkit → Seamonkey
You need to log in before you can comment on or make changes to this bug.