Closed Bug 280154 Opened 19 years ago Closed 19 years ago

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

Categories

(SeaMonkey :: Help Viewer, defect, P1)

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: aaronlev, Assigned: aaronlev)

References

(Blocks 1 open bug)

Details

(Keywords: access, helpwanted)

Attachments

(3 files)

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.
This makes help unusable for non-mouse users.
Flags: blocking-aviary1.1?
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
Flags: blocking-aviary1.1?
Product: Firefox → Toolkit
Target Milestone: Firefox1.1 → ---
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.
(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.
(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.
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.
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+
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+
/cvsroot/mozilla/layout/base/nsPresShell.cpp,v  <--  nsPresShell.cpp
new revision: 3.830; previous revision: 3.829
done
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Blocks: 295904
Flags: in-testsuite?
Product: Toolkit → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: