The "meatball" and "chevron" menus remain open inside a newly opened tab

VERIFIED FIXED in Firefox 64

Status

defect
P3
normal
VERIFIED FIXED
8 months ago
7 months ago

People

(Reporter: emilghitta, Assigned: mantaroh)

Tracking

(Blocks 1 bug, {regression})

Trunk
Firefox 64
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox62 unaffected, firefox63 wontfix, firefox64 verified, firefox65 verified)

Details

Attachments

(2 attachments)

Reporter

Description

8 months ago
Posted image NewTab.gif
[Affected versions]:
64.0a1 (BuildId:20180910220142)
63.0b5 (BuildId:20180910132416)

[Unaffected versions]: 
62.0 (BuildId:20180830143136)
60.2.0esr (BuildId:)

[Affected platforms]:
Windows 10 64bit.
Ubuntu 16.04 64bit.
macOS 10.13.6

[Steps to reproduce]:
1. Launch Firefox.
2. Open the developer tools.
3. Open the "meatball" menu.
4. Press the "CTRL" + "t" keyboard combination (Or "Command" + "t") in order to open a new tab.

[Expected result]:
A new tab is successfully displayed and the meatball menu is not displayed.

[Actual result]:
A new tab is displayed and the meatball menu remains open.

[Regression range]:
This seems to be a regression.

Mozregression points out Bug 1461522 for causing this regression.

Last good revision: ea72ff9a6e23abf3aa52aaaf06a9ba8b18ca39c7
First bad revision: cc6ec2789c9d50a686f4df5a70bf0f1173d1d32e

Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ea72ff9a6e23abf3aa52aaaf06a9ba8b18ca39c7&tochange=cc6ec2789c9d50a686f4df5a70bf0f1173d1d32e

[Note]
For further information regarding this issue please observe the attached screencast.
Reporter

Updated

8 months ago
See Also: → 1490362
Reporter

Updated

8 months ago
Blocks: 1468999
Priority: -- → P3
See also attachment 9008088 [details] from bug 1490362 for the chevron case.
Summary: The "meatball" menu remains open inside a newly opened tab → The "meatball" and "chevron" menus remain open inside a newly opened tab
Duplicate of this bug: 1490362
Assignee

Comment 3

8 months ago
I thought that we can use the 'visibilitychange' event from this window. However, devtool's iframe is XUL. So this event doesn't support on platform-level[1]. So we need to detect visibility in the other way.

[1] https://searchfox.org/mozilla-central/rev/80ac71c1c54af788b32e851192dfd2de2ec18e18/devtools/client/framework/toolbox.js#1876
Assignee: nobody → mantaroh
Status: NEW → ASSIGNED
(In reply to Mantaroh Yoshinaga[:mantaroh] from comment #3)
> I thought that we can use the 'visibilitychange' event from this window.
> However, devtool's iframe is XUL. So this event doesn't support on
> platform-level[1]. So we need to detect visibility in the other way.
> 
> [1]
> https://searchfox.org/mozilla-central/rev/
> 80ac71c1c54af788b32e851192dfd2de2ec18e18/devtools/client/framework/toolbox.
> js#1876

FWIW we would like to change this so that the toolbox window is HTML. I guess the timeline for that work may not line up with getting this bug fixed, but it'd be worth at least having a comment / follow up bug to switch to the event. Honza, is there a bug to block that on? I see Bug 1251394 (filed as part of Bug 1178254), but I thought there may have been another bug on file that had more context.
Flags: needinfo?(odvarko)
(In reply to Brian Grinstead [:bgrins] from comment #4)
> FWIW we would like to change this so that the toolbox window is HTML. I
> guess the timeline for that work may not line up with getting this bug
> fixed, but it'd be worth at least having a comment / follow up bug to switch
> to the event. Honza, is there a bug to block that on? I see Bug 1251394
> (filed as part of Bug 1178254), but I thought there may have been another
> bug on file that had more context.
I think the Bug 1251394 is the right one to block on (I don't know about any other report)

Honza
Flags: needinfo?(odvarko)
Assignee

Comment 6

7 months ago
Thanks, bgrins,

I'd like to address this phenomenon before converting toolbox to HTML, and I'll file the another bugs to block the bug 1251394.

WIP:
https://hg.mozilla.org/try/rev/b6e76221bf8906ef3ad445914df27bf4985a68ed
Assignee

Comment 7

7 months ago
If push the ctrl+t, browser will open the new tab. In this case,
the XUL popup panel doesn't hide automatically(autohide=false).
As the result of it, the popup menu will be displayed in the new tab
content. So this patch will hide the popup when receiving the ctr+t
shortcut in the MenuButton.

Comment 8

7 months ago
Pushed by mantaroh@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/d5cc1ab5bb16
Hide menu popup when press the ctrl+t. r=birtles

Comment 9

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/d5cc1ab5bb16
Status: ASSIGNED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Reporter

Comment 11

7 months ago
This issue is verified fixed using Firefox 64.0a1 (BuildId:20181016220050) on Windows 10 64bit, macOS 10.14 and Ubuntu 16.04 64bit.
Status: RESOLVED → VERIFIED

Comment 12

7 months ago
Verified fixed on Firefox 64.0a1 on Windows 10x64 and Ubuntu 17.10


Additionally tested on latest Nightly.Works as expected 
Build ID 	20181026100128
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0

Updated

7 months ago
You need to log in before you can comment on or make changes to this bug.