64606 - page accesskeys don't work when location bar has focus

Status: VERIFIED DUPLICATE of bug 129808

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

Description

[Jesse Ruderman]

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

[Håkan Waara]

Good catch. Cc:ing myself...

Comment 2

[timeless]

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

[Matthew T (active 1999-2002)]

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.

Comment 4

[sairuh (rarely reading bugmail)]

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

[Blake Ross]

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

[Akkana Peck]

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.

Comment 7

[Jesse Ruderman]

See bugs linked from bug 55416 for discussion about whether the location bar 
should have focus when you open a new window.

Comment 8

[sairuh (rarely reading bugmail)]

interestingly, check out bug 57078...

Comment 9

[Chris McAfee]

nsbeta1

Comment 10

[Chris McAfee]

+ p2

Comment 11

[sairuh (rarely reading bugmail)]

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.]

Comment 12

[Jesse Ruderman]

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.

Comment 13

[Viswanath Ramachandran]

moving to mozilla 0.9 

Comment 14

[Paul Chen]

This doesn't sound like something that needs to be done for mozilla0.9,
resetting mozilla0.9, marking nsbeta1-

Comment 15

[Paul Chen]

Alright, let's get this done, marking nsbeta1+, mozilla0.9

Comment 16

[Alec Flett]

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.

Comment 17

[Aaron Leventhal]

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

[timeless]

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

[Paul Chen]

Resetting target milestone, need to retriage

Comment 20

[Jesse Ruderman]

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

Comment 21

[Paul Chen]

nav triage team:

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

Comment 22

[Alec Flett]

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?

Comment 23

[Aaron Leventhal]

-> blake, location bar issues
(alecf should never have had this one)

Comment 24

[Blake Ross]

reassigning to default owner.

Comment 25

[Aaron Leventhal]

-> saari, triage

Comment 26

[Jesse Ruderman]

See also bug 129808, pref panel accesskeys don't work when category tree or
dialog button has focus.

Comment 27

[Jesse Ruderman]

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

Comment 28

[Aaron Leventhal]

-> Akkana, this might be the same as the fix for acceskeys in the multi-iframe
dialogs such as prefs.

Comment 29

[Jesse Ruderman]

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

[Akkana Peck]

Adding bryner, since this seems like primarily a focus issue.

Comment 31

[Aaron Leventhal]

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.

Comment 32

[Gilbert Fang]

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. :-)

Comment 33

[Gilbert Fang]

please see my patch for bug 129808. it can also fix this bug. 

Comment 34

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 129808 ***

Comment 35

[sairuh (rarely reading bugmail)]

mass-verification of Duplicates.

mail search string for bugspam: SolarFlaresAreTheCause