Open Bug 501419 Opened 15 years ago Updated 1 year ago

Web Pages Capture Control-L


(Firefox :: Keyboard Navigation, enhancement)

Windows XP





(Reporter: thangalin, Unassigned)




User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv: Gecko/2009060215 Firefox/3.0.11

Certain websites will capture useful keystrokes, preventing them from functioning.

Reproducible: Always

Steps to Reproduce:
1. Create an account on StackOverflow (
2. Go to
3. Select any question (e.g., What's your favourite "programmer" cartoon?)
4. Scroll to the bottom of the page.
5. Type a few words into the "Your Answer" text area.
6. Press CONTROL-L (lowercase L or uppercase, does not matter)

Actual Results:  
The JavaScript overrides the default behaviour of CONTROL-L.

Expected Results:  
Focus should change to the address location bar in Firefox (the default behaviour).

Would be nice to prohibit websites from taking over specific keys. Firefox should have intercepted the CONTROL-L, prompting me to permit or deny the ability for the site to override those keystrokes.
This is not 78414. This is invalid javascript/dom provides a way to capture keystrokes. Changing this would mean breaking or having an inconstant behavior for and
Another way to resolve it would be to have a setting that allows a user to request that Firefox does not allow applications to override certain keystrokes (Control-L, Control-O, Control-R, Control-T, etc.).

As an end-user, I don't really care what the *website* wants to do with Control-L. I want to change the website address from the keyboard. Perhaps having a pop-up to allow the web-page control over the keyboard shortcuts is a bit much. 

I see nothing wrong with having a setting that allows you to block applications from overriding Firefox's own shortcuts.
This bug is becoming increasingly annoying as websites become more and more javascript-rich.

In particular, the capturing of ctrl-t (for new tab) drives me completely insane.

I consider this to be a bug, not an enhancement. The order of keyevent handling should be Firefox -> website, just as for window managers it is windowmanager -> application. If Firefox has a function for some event then that event should *always* work, regardless of the website.

Kevin, why would fixing this create inconsistent behaviour for onkeypress? If websites simply never see 'ctrl-t' or 'ctrl-l' then it shouldn't matter. Of course, that assumes that onkeypress uses a modifier system. If pressing ctrl by itself is meant to create an event then this is going to be harder to fix.

Google Chrome appears to get this right- I haven't had any shortcut-stealing issues with that. Maybe someone else could provide a counter-example?

This bug is still present with Firefox 7.0.1 and it applies to Linux as well.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.