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)
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•7 years ago
|
Priority: -- → P3
Comment 1•7 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•7 years ago
|
| Assignee | ||
Comment 3•7 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•7 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•7 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•7 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•7 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•7 years ago
|
||
| bugherder | ||
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 64
Comment 10•7 years ago
|
||
Too late for 63.
| Reporter | ||
Comment 11•7 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•7 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•7 years ago
|
status-firefox65:
--- → verified
You need to log in
before you can comment on or make changes to this bug.
Description
•