Closed Bug 1490358 Opened 7 years ago Closed 7 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
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
Status: ASSIGNED → RESOLVED
Closed: 7 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.

Attachment

General

Created:
Updated:
Size: