Alt+Tab sometimes causes the menubar to unhide briefly

VERIFIED FIXED in mozilla1.9.3a4

Status

()

Core
Widget: Win32
--
trivial
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: dao, Assigned: neil@parkwaycc.co.uk)

Tracking

({regression, verified1.9.2})

Trunk
mozilla1.9.3a4
x86
Windows XP
regression, verified1.9.2
Points:
---

Firefox Tracking Flags

(status1.9.2 .4-fixed, status1.9.1 .10-fixed)

Details

(Whiteboard: calm-ui)

Attachments

(1 attachment, 3 obsolete attachments)

Comment hidden (empty)
(Reporter)

Updated

8 years ago
Whiteboard: calm-ui
(Reporter)

Comment 1

8 years ago
Created attachment 409613 [details] [diff] [review]
patch
Attachment #409613 - Flags: review?(neil)
(Reporter)

Comment 2

8 years ago
Created attachment 409614 [details] [diff] [review]
patch v2

Err, of course I shouldn't use Cc and Ci here.
Attachment #409613 - Attachment is obsolete: true
Attachment #409614 - Flags: review?(neil)
Attachment #409613 - Flags: review?(neil)
(Reporter)

Comment 3

7 years ago
Created attachment 424480 [details] [diff] [review]
patch v2

updated to tip
Attachment #409614 - Attachment is obsolete: true
Attachment #424480 - Flags: review?(neil)
Attachment #409614 - Flags: review?(neil)
(Assignee)

Comment 4

7 years ago
Sorry, but I just haven't been able to reproduce this, either by Alt+Tabbing to another application or to another window in the same Gecko application.
(Reporter)

Comment 5

7 years ago
Can you still review the code? Considering the menubar active in an inactive window doesn't make sense either way.

It happens for me every second try, approximately. But as I said, it's probably system dependent.
(Reporter)

Updated

7 years ago
Attachment #424480 - Flags: review?(neil) → review?(enndeakin)

Comment 6

7 years ago
Comment on attachment 424480 [details] [diff] [review]
patch v2

>+      <property name="_isWinActive" readonly="true">
>+        <getter><![CDATA[
>+          var fm = Components.classes["@mozilla.org/focus-manager;1"]
>+                             .getService(Components.interfaces.nsIFocusManager);
>+          return window == fm.activeWindow;

Should we be concerned that this will only work if the <menubar> is in the toplevel window?


>+      <handler event="DOMMenuBarActive"><![CDATA[
>+        // It's possible that we're getting DOMMenuBarActive even if the window
>+        // isn't active anymore because of Alt+Tab.

Isn't that a bug in itself?

I don't see the bug though. DOMMenuBarActive should be sent on keyup, so the menu shouldn't be triggered then. Maybe some locale keyboard difference?
(Reporter)

Comment 7

7 years ago
(In reply to comment #6)
> (From update of attachment 424480 [details] [diff] [review])
> >+      <property name="_isWinActive" readonly="true">
> >+        <getter><![CDATA[
> >+          var fm = Components.classes["@mozilla.org/focus-manager;1"]
> >+                             .getService(Components.interfaces.nsIFocusManager);
> >+          return window == fm.activeWindow;
> 
> Should we be concerned that this will only work if the <menubar> is in the
> toplevel window?

I don't think so... auto-hiding doesn't make sense for other menubars, since Alt wouldn't activate them.

> >+      <handler event="DOMMenuBarActive"><![CDATA[
> >+        // It's possible that we're getting DOMMenuBarActive even if the window
> >+        // isn't active anymore because of Alt+Tab.
> 
> Isn't that a bug in itself?
> 
> I don't see the bug though. DOMMenuBarActive should be sent on keyup, so the
> menu shouldn't be triggered then. Maybe some locale keyboard difference?

I think it's because the event is async and the netbook I'm running Win XP on is rather slow...

Comment 8

7 years ago
> > I don't see the bug though. DOMMenuBarActive should be sent on keyup, so the
> > menu shouldn't be triggered then. Maybe some locale keyboard difference?
> 
> I think it's because the event is async and the netbook I'm running Win XP on
> is rather slow...

DOMMenuBarActive shouldn't be firing at all.

Can you debug here a bit a find out what menu/popups related events and key events are actually firing when?
(Reporter)

Comment 9

7 years ago
When releasing Alt+Tab quickly, regardless of whether the menu bar shows up, I get these events:

keydown, keyup, deactivate, DOMMenuBarActive, DOMMenuItemActive, DOMMenuBarInactive, DOMMenuItemInactive

If I release Tab and wait a bit before releasing Alt, the menu bar never shows up and I get these events:

keydown, keyup, keyup, deactivate
(Assignee)

Comment 10

7 years ago
This is actually a regression of bug 262894 by bug 272847.
Assignee: dao → nobody
Blocks: 272847
No longer blocks: 477256
Component: Toolbars and Toolbar Customization → Widget: Win32
Keywords: polish → regression
Product: Toolkit → Core
QA Contact: toolbars → win32
Version: 1.9.2 Branch → Trunk
(Reporter)

Updated

7 years ago
Attachment #424480 - Flags: review?(enndeakin)
(Assignee)

Comment 11

7 years ago
Created attachment 434643 [details] [diff] [review]
Proposed patch
Assignee: nobody → neil
Attachment #424480 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #434643 - Flags: review?(jmathies)

Comment 12

7 years ago
Comment on attachment 434643 [details] [diff] [review]
Proposed patch

oops!
Attachment #434643 - Flags: review?(jmathies) → review+
(Assignee)

Comment 13

7 years ago
Pushed changeset 91897531cbf5 to mozilla-central.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 14

7 years ago
Comment on attachment 434643 [details] [diff] [review]
Proposed patch

Seeking approval for this simple fix for the branches where the regression typo landed.
Attachment #434643 - Flags: approval1.9.2.3?
Attachment #434643 - Flags: approval1.9.1.10?
(Reporter)

Comment 15

7 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100326 Minefield/3.7a4pre

Works like a charm.
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.3a4
Comment on attachment 434643 [details] [diff] [review]
Proposed patch

a=beltzner for 1.9.1.10 and 1.9.2.3
Attachment #434643 - Flags: approval1.9.2.3?
Attachment #434643 - Flags: approval1.9.2.3+
Attachment #434643 - Flags: approval1.9.1.10?
Attachment #434643 - Flags: approval1.9.1.10+
(Assignee)

Comment 17

7 years ago
Pushed changeset 499f6d27d231 to releases/mozilla-1.9.2

Pushed changeset 0865dc62ccad to releases/mozilla-1.9.1
status1.9.1: --- → .10-fixed
status1.9.2: --- → .3-fixed
Dão can you verify this with the nightly 1.9.2 and 1.9.1 builds since you can reproduce the problem easily?
(Reporter)

Comment 19

7 years ago
Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9.2.4pre) Gecko/20100413 Namoroka/3.6.4pre
Keywords: verified1.9.2
(Reporter)

Comment 20

7 years ago
Cannot verify on 1.9.1, as the menu bar doesn't support auto-hiding there.
Thanks!
You need to log in before you can comment on or make changes to this bug.