Closed Bug 88239 Opened 23 years ago Closed 22 years ago

Keyboard navigation is impossible when Navigation Toolbar is hidden when started up

Categories

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

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: doctor__j, Assigned: bryner)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [fixed on trunk])

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010627
BuildID:    2001062706

Reproducible: Always
Steps to Reproduce:
1. Hide Navigation Toolbar in "View -> Show/Hide" menu.
2. Close Mozilla.
3. Start Mozilla.
4. No keyboard navigation can be deployed.  Cannot open File menu or anything!

Expected Results:  At least be able to pull down a menu from the menu bar.
hm, this works for me *if* i click the content area before doing a keyboard
shortcut [tested on linux, 2001.06.27.07-branch comm]. however, i wonder if bug
73064 is interfering --since i don't need to click the content area if the
Navigation toolbar is present/open.

bryner/jesse, d'you think this is a dup of bug 69504? [it's at least a variation
of it...]
Assignee: alecf → bryner
also see this on Mac.
OS: Windows 98 → All
Hardware: PC → All
Focus would normally be in the location bar on startup, but since the location
bar doesn't exist, nothing has focus and so keyboard shortcuts don't work.  The
content area should get initial focus on window creation if the location bar
isn't visible.
Blocks: 55416
so this isn't a toolkit bug, is it? sounds like xpapps needs to put focus in the 
right place
Assignee: bryner → aaronl
hrm, xpapps for real
Assignee: aaronl → vishy
Keywords: nsbeta1
->aaronl for traige, cc'ing some xp apps...
Assignee: vishy → aaronl
-> xpapps
Assignee: aaronl → pchen
nav triage team:

Marking nsbeta1+, p3, and mozilla1.0
Keywords: nsbeta1nsbeta1+
Priority: -- → P3
Target Milestone: --- → mozilla1.0
Keywords: access
*** Bug 108244 has been marked as a duplicate of this bug. ***
moving to mozilla0.9.9
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9
->default assignee
Assignee: pchen → aaronl
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.9 → ---
-> trudelle, for retriage
Assignee: aaronl → trudelle
->bryner
Assignee: trudelle → bryner
*** Bug 104003 has been marked as a duplicate of this bug. ***
Attached patch patchSplinter Review
don't try to focus the urlbar if the toolbar isn't visible.
Nominating for beta... we should consider this since it's an easy fix for (what
amounts to) total loss of functionality if you are a keyboard-only user and
happen to choose the menu item to hide the navigation toolbar.
Keywords: nsbeta1
Comment on attachment 79550 [details] [diff] [review]
patch

sr=jag
Attachment #79550 - Flags: superreview+
Comment on attachment 79550 [details] [diff] [review]
patch

r=sgehani
Attachment #79550 - Flags: review+
Nav triage team: nsbeta1-

Please check this into the trunk.  
Keywords: nsbeta1nsbeta1-
Fixed on the trunk.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Whiteboard: [fixed on trunk]
vrfy'd fixed with 2002.06.17.0x comm trunk bits on linux rh7.2, win2k and mac
10.1.5...although, interestingly, this no longer seems a problem on the branch
either. perhaps the fix to bug 37638 might've affected this on this branch?
Status: RESOLVED → VERIFIED
not found
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
blocking-basecamp: ? → ---
blocking-kilimanjaro: ? → ---
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: