Closed Bug 84687 Opened 23 years ago Closed 19 years ago

Control+L opens navigation toolbar permanently


(SeaMonkey :: UI Design, defect)

Windows NT
Not set


(Not tracked)



(Reporter: j.willeke, Assigned: bugzilla)


(Keywords: access)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607
BuildID:    2001060703

I've hidden the navigation toolbar, because of the massive buttons.  Eventually,
I'll get a theme with smaller buttons, but for now I just want it hidden.
Pressing <Ctrl>-l exposes the toolbar for this and all future sessions.

Reproducible: Always
Steps to Reproduce:
1. Open a browser session, with the navigation toolbar hidden.
2. Click somewhere in the session, so it will accept keyboard events.
3. Press <Ctrl>-l.
4. Open a new browser session.

Actual Results:  The navigation toolbar popped up in both browser sessions.

Expected Results:  Ideally, the open web dialog would have opened.
Anyway, <Ctrl>-l should not override my global preferences.
It took me at least three mouse clicks to hide the thing in the first place.
I agree w/ the reporter's expected results.
Assignee: asa → mpt
Component: Browser-General → User Interface Design
Ever confirmed: true
QA Contact: doronr → zach
I agree, with one minor difference.

I think that when the toolbar is hidden, Ctrl+L should open it *temporarily* 
until focus leaves the address field (by pressing Enter after typing the URL, 
or by clicking elsewhere, or by Tabbing out of the address field, or by typing 
Ctrl+L again). This would be less intrusive, and much less surprising, than 
opening the Open Location dialog for a keyboard shortcut which was defined for 
something else.

--> XP Apps: GUI.
Assignee: mpt → blake
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
Summary: <Ctrl>-l exposes navigation toolbar → Control+L opens navigation toolbar permanently
Target Milestone: --- → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Ctrl-L does not appear to be defined in the UI currently, so I'm not sure what
users expect.  I suspect that just changing focus is a bit too subtle for most
users to discover, especially if they are looking at the keyboard when they do
it.   I'm pretty sure that the current behavior has naturally become part of the
user model for anyone that has noticed it, since there is no way to know it is
'wrong'.   I'm also concerned that having the location bar disappear by itself
after entering the URL could be bad, since users may be focussed there.  Having
things disappear that I didn't dismiss seems much more surprising to me than
things that appear in response to my command.  I'm not sure why this was changed
from the 4.x behavior to begin with, as I don't recall getting a lot of
complaints about there being a dialog for this, although the way the dialog was
done was rather clunky.  I think having Ctrl-L defined in the menus as toggling
the location bar and moving the focus might be a good solution though.
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
 If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.2
Duplicate of bug 81331?
Product: Core → Mozilla Application Suite

FWIW - ctrl-shift-L now provides the required functionality without involving the navigation bar.

*** This bug has been marked as a duplicate of 81331 ***
Closed: 19 years ago
Resolution: --- → DUPLICATE
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.