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.

Good catch. Cc:ing myself...

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?

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.

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.

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.

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.

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

nsbeta1

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

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

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

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

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.

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.

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.

Resetting target milestone, need to retriage

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

nav triage team: Don't think this is a beta1 stopper, marking nsbeta1-

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?

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

reassigning to default owner.

-> saari, triage

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

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

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

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.

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

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.

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

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

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

mass-verification of Duplicates. mail search string for bugspam: SolarFlaresAreTheCause