Closed
Bug 1490358
Opened 5 years ago
Closed 5 years ago
The "meatball" and "chevron" menus remain open inside a newly opened tab
Categories
(DevTools :: General, defect, P3)
DevTools
General
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)
[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.
Updated•5 years ago
|
Priority: -- → P3
Comment 1•5 years ago
|
||
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
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years 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
Comment 4•5 years ago
|
||
(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)
Comment 5•5 years ago
|
||
(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•5 years 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•5 years 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.
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•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d5cc1ab5bb16
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Comment 10•5 years ago
|
||
Too late for 63.
Reporter | ||
Comment 11•5 years 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•5 years 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•5 years ago
|
status-firefox65:
--- → verified
You need to log in
before you can comment on or make changes to this bug.
Description
•