1044170 - Accidental Alt press opens File menu, stealing subsequent Ctrl- and Alt- shortcuts

Status: RESOLVED DUPLICATE of bug 971011

(Firefox :: Keyboard Navigation, defect)

Description

[Federico]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release)
Build ID: 20140611060104

Steps to reproduce:

1) Press alt
2) Press some other key like d, or ctrl-t


Actual results:

Since Firefox 30.0, when the Alt key is released, the commands (File/Edit etc.) menu (normally hidden) opens, and stays open until the next keystroke or click. The next keystroke is interpreted as a shortcut to open a menu dropdown, for instance Tools if I press t.

This systematically steals my alt-d and ctrl-t shortcuts making tab navigation very frustrating.


Expected results:

Alt alone shouldn't do anything, and especially not after it's released.

Comment 1

[Federico]

Ah, sorry, automatic user-agent info didn't tell: this is fedora 20, KDE. 3.15.6-200.fc20.x86_64 #1 SMP Fri Jul 18 02:36:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Comment 2

[:Gijs (out for now; he/him)]

Did this work in Firefox 29? Does it work with a clean profile (with any distribution-provided add-ons disabled) on an official build of Firefox 30/31 instead of the Fedora version?

We aimed to fix this in bug 940040, for Firefox 29, with a followup fix in bug 966683. I don't know what/how this would have broken again. Can you get a regression window with mozregression, perhaps? ( http://mozilla.github.io/mozregression/ )

Comment 3

[:Gijs (out for now; he/him)]

Also, rereading your initial report, I'm confused... how are you activating a shortcut like "alt-d" *after* releasing the alt key? Is this a GTK/window-manager/application-provided "sticky key" functionality of sorts?

Comment 4

[[:Aleksej]]

Gijs, I thought it was about an accidental press of Alt, which leaves the menu bar open and active.

Comment 5

[:Gijs (out for now; he/him)]

(In reply to [:Aleksej] from comment #4)
> Gijs, I thought it was about an accidental press of Alt, which leaves the
> menu bar open and active.

That doesn't match:

(In reply to Federico from comment #0)
> This systematically steals my alt-d and ctrl-t shortcuts making tab
> navigation very frustrating.

If it's only about accidental *additional* presses of alt before hitting a shortcut, that is hardly "systematic"...

Comment 6

[[:Aleksej]]

I can't come up with any Alt- shortcut it interferes with (if it's locale-dependent, they would always suffer already), but yes Ctrl-t, Ctrl-l, Ctrl-k.

Comment 7

[[:Aleksej]]

> If it's only about accidental *additional* presses of alt before hitting a shortcut, that is hardly "systematic"...

Maybe because GTK programs do nothing with Alt alone.  Qt ones do though…

Comment 8

[Federico]

(In reply to :Gijs Kruitbosch (Bugmail catchup, needinfo if urgent) from comment #2)
> Did this work in Firefox 29? 

Yes, AFAIK.

> Does it work with a clean profile (with any
> distribution-provided add-ons disabled) on an official build of Firefox
> 30/31 instead of the Fedora version?
> 
> We aimed to fix this in bug 940040, for Firefox 29, with a followup fix in
> bug 966683. I don't know what/how this would have broken again. Can you get
> a regression window with mozregression, perhaps? (
> http://mozilla.github.io/mozregression/ )

Last time I used mozregression it it had a bug which was never fixed IIRC. I may try a clean profile soonish but I can't today.

(In reply to :Gijs Kruitbosch (Bugmail catchup, needinfo if urgent) from comment #3)
> how are you activating
> a shortcut like "alt-d" *after* releasing the alt key?

By pressing alt-d again. For instance, I (try to) press alt-d to copy URL, it doesn't work, I do ctrl-l, I take my URL, I press ctrl-t, Tools open, I do alt-d, downloads opens etc. And then I discover that's because the initial alt-d was not fast enough or something and activated the menu -> chain effect.

I don't know... I don't mean to surveil my muscle memory in its interactions with my software.

I'd just like to know whether it's intended that 1) Alt alone activates the menus, 2) they stay permanently active even after releasing Alt, until I press Alt again or click somewhere. If either is a "yes", I can't be bothered using this version and I'll just stick with 1.25 (currently downgrading), until I manage to find a way to disable Alt without disabling all the alt-shift-key shortcuts of websites.

Comment 9

[[:Aleksej]]

> until I manage to find a way to disable Alt without disabling all the alt-shift-key shortcuts of websites.

Just enable Menu bar permanently.

Comment 10

[Federico]

(In reply to [:Aleksej] from comment #9)
> Just enable Menu bar permanently.

Yeah, true, that helps. :-)

Comment 11

[:Gijs (out for now; he/him)]

(In reply to Federico from comment #8)
> I'd just like to know whether it's intended that 1) Alt alone activates the
> menus, 2) they stay permanently active even after releasing Alt, until I
> press Alt again or click somewhere.

Yes and yes.

(In reply to Federico from comment #10)
> (In reply to [:Aleksej] from comment #9)
> > Just enable Menu bar permanently.
> 
> Yeah, true, that helps. :-)

I'm glad this helps. I'm going to mark this as a duplicate of bug 971011, where the reporter had a similar request to remove the "alt shows the menubar" functionality.