Closed Bug 1490358 Opened 2 years ago Closed 2 years ago

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

Categories

(DevTools :: General, defect, P3)

defect

Tracking

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

VERIFIED FIXED
Firefox 64
Tracking Status
firefox-esr60 --- unaffected
firefox62 --- unaffected
firefox63 --- wontfix
firefox64 --- verified
firefox65 --- verified

People

(Reporter: emilghitta, Assigned: mantaroh)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

Attached 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.
See Also: → 1490362
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
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)
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
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.
Pushed by mantaroh@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/d5cc1ab5bb16
Hide menu popup when press the ctrl+t. r=birtles
https://hg.mozilla.org/mozilla-central/rev/d5cc1ab5bb16
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
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
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
You need to log in before you can comment on or make changes to this bug.