If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

page accesskeys don't work when location bar has focus

VERIFIED DUPLICATE of bug 129808

Status

()

Core
Keyboard: Navigation
P2
normal
VERIFIED DUPLICATE of bug 129808
17 years ago
15 years ago

People

(Reporter: Jesse Ruderman, Assigned: Gilbert Fang)

Tracking

({access})

Trunk
Future
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [KEYBASE+], URL)

(Reporter)

Description

17 years ago
Accesskeys (Alt-S, etc.) on http://www.cs.hmc.edu/~jruderma/s/ don't work when 
the location bar has focus.  This is pretty annoying since the location bar has 
focus when I start the browser.

Comment 1

17 years ago
Good catch. Cc:ing myself...

Comment 2

17 years ago
personally i think this is a disaster.  while chrome is controlling bindings, 
html shouldn't interfere, and while html is binding chrome shouldn't interfere 
see my comments in bug 959.

would my solution satisfy your needs?

Comment 3

17 years ago
No, this bug is valid (and expected behavior works in Internet Explorer). 
Timeless's proposed solution to bug 959 would work very well for the sort of 
people who like using the vi editor, but it would be incomprehensible to everyone 
else.
OS: Windows 98 → All
Hardware: PC → All
i might be misunderstanding this bug, but afaik, the default focus [when you
start the browser or open a new browser window] is supposed to be the location
bar. and because of that, keyboard accelerators for the browser shouldn't work.
i think.

cc'ing akkana and blake for further comments.

Comment 5

17 years ago
Further comments:

I think they should work when the location bar has focus.  Many people won't 
make the distinction between chrome and content that timeless is trying to.  
And it won't make much logical sense to people that they need to click in the 
content area before their keystrokes will work, since they won't see a 
correlation between the two.

Comment 6

17 years ago
That would be nice.  The problem is that if we use ctrl as the accel key, we
have quite a few conflicts between the window bindings and the text editing
bindings.
(Reporter)

Comment 7

17 years ago
See bugs linked from bug 55416 for discussion about whether the location bar 
should have focus when you open a new window.
interestingly, check out bug 57078...

Comment 9

17 years ago
nsbeta1
Keywords: nsbeta1

Comment 10

17 years ago
+ p2
Priority: -- → P2
ooh, i just realize i might've misunderstood the summary of this bug. jesse,
when you mean access keys, d'you mean, for example, doing Alt+S to drop down the
Search menu? if yes, pls disregard the 'keyboard accelerator' phrase in my
2001-01-08 14:11 comment. [doh! /me apologizes.]
(Reporter)

Comment 12

17 years ago
I meant Alt+S to focus the Slashdot link on the page, which has accesskey="s".  
Sorry for the confusion... I should have used an example that doesn't have a 
meaning to the browser on most pages, such as Alt+3 for Google.
moving to mozilla 0.9 
Target Milestone: --- → mozilla0.9

Comment 14

17 years ago
This doesn't sound like something that needs to be done for mozilla0.9,
resetting mozilla0.9, marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla0.9 → ---
(Reporter)

Updated

17 years ago
Keywords: mozilla0.9.1

Updated

17 years ago
Target Milestone: --- → mozilla1.0

Comment 15

17 years ago
Alright, let's get this done, marking nsbeta1+, mozilla0.9
Keywords: nsbeta1- → nsbeta1+
Target Milestone: mozilla1.0 → mozilla0.9

Comment 16

17 years ago
Wait a sec. where is this accesskey="s"? We've established that this is neither
a menu key nor a accelerator key...

is it ON your bookmarks? or is it on the slashdot page (because I don't see it
in the source)
whether it's on the page or in the bookmarks, I don't see how this is a beta
stopper..

moving back to nsbeta1 status so we can reevaluate it.
Keywords: nsbeta1+ → nsbeta1

Comment 17

17 years ago
For an example of a page accesskey attribute in HTML, go to
www.microsoft.com/enable. Typing Alt+S in Windows brings up a site search page.
This is done via an accesskey="S" attribute on the appropriate link.

I think Alt+S works in Unix as well, and Ctrl+S is supposed to work on Mac.

Comment 18

17 years ago
alecf: see the url field and original bug comment. again this is a mess and a 
nightmare. However, i agree that this is not worth marking as nsbeta1+ because 
there is no conclusion by the userbase about what they want.

This bug should not be assigned to a developer (ie: alecf) until someone has 
decided what is wanted.

Comment 19

17 years ago
Resetting target milestone, need to retriage
Target Milestone: mozilla0.9 → ---
(Reporter)

Comment 20

17 years ago
timeless: you seem to be the only person who disagrees with this bug report...

Comment 21

17 years ago
nav triage team:

Don't think this is a beta1 stopper, marking nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 22

17 years ago
I really have no idea how to fix this and I feel like this would need some kind
of keyboard/focus/editor guru. Anyone in editor want to take a shot at this?
Target Milestone: --- → mozilla1.0

Updated

16 years ago
Blocks: 55416

Updated

16 years ago
No longer blocks: 55416

Comment 23

16 years ago
-> blake, location bar issues
(alecf should never have had this one)
Assignee: alecf → blake

Comment 24

16 years ago
reassigning to default owner.
Assignee: blakeross → aaronl
Target Milestone: mozilla1.0 → ---

Comment 25

16 years ago
-> saari, triage
Assignee: aaronl → saari
Keywords: access

Updated

16 years ago
Target Milestone: --- → mozilla1.0.1
(Reporter)

Comment 26

16 years ago
See also bug 129808, pref panel accesskeys don't work when category tree or
dialog button has focus.
(Reporter)

Comment 27

16 years ago
See also bug 147692, QuickSearch mnemonics don't work if focus in mail window
msg pane.

Comment 28

16 years ago
-> Akkana, this might be the same as the fix for acceskeys in the multi-iframe
dialogs such as prefs.
Assignee: saari → akkana
Whiteboard: [KEYBASE+]
(Reporter)

Comment 29

15 years ago
See also bug 143065, "Scope of accesskey should be limited to a tab panel". 
This could get tricky, since the prefs dialog has panels (similar to dialog
tabs).  Accesskeys in the current panel should work while focus is in the
category list, but accesskeys in other panels should not work.

Comment 30

15 years ago
Adding bryner, since this seems like primarily a focus issue.
Target Milestone: mozilla1.0.1 → Future

Comment 31

15 years ago
This sounds like the bug where accesskeys in the prefs panel don't work when the
category pane has focus. Accesskeys need to be done through the dom or they need
to be offered throughout the esm tree.
Assignee: akkana → gilbert.fang
(Assignee)

Comment 32

15 years ago
yes, actually, i think this bug is just like 129808. 
If u used xul-widget like iframe or tabbox which has accesskeys, but the windows
does not know it,then when the focus is not in that widget, the key press event
only can bubbled to the window and does not bubble down. 
Now I try to add a event bubble down  process to resolve this kind of problem. 
Please see the http://bugzilla.mozilla.org/show_bug.cgi?id=129808#c9 and
http://bugzilla.mozilla.org/show_bug.cgi?id=129808#c10 . 
I have to be very careful so as to avoid a event storm. :-)
(Assignee)

Comment 33

15 years ago
please see my patch for bug 129808. it can also fix this bug. 
(Reporter)

Comment 34

15 years ago

*** This bug has been marked as a duplicate of 129808 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.