Open Bug 1487107 Opened 6 years ago Updated 5 months ago

The "meatball" menu remains displayed as enabled after being closed

Categories

(DevTools :: General, defect, P5)

defect

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 wontfix, firefox65 fix-optional)

Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- wontfix
firefox65 --- fix-optional

People

(Reporter: emilghitta, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

Attached image issue.gif
[Affected versions]:
63.0a1 (BuildId:20180829100131)
62.0 (BuildId:20180827144429)
61.0.2 (BuildId:20180807170231)

[Unaffected versions]: 
60.1.0esr (BuildId:20180621121604)

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

[Steps to reproduce]:
1. Launch Firefox.
2. Open the developer tools.
3. Click on the "meatball" menu.
4. Close the "meatball" menu.

[Expected result]:
The "meatball" menu button is displayed as disabled.

[Actual result]:
The "meatball" menu button is displayed as enabled.

[Regression range]:
I don't think that this is a regression.

[Note]
For further information regarding this issue please observe the attached screencast.
The "meatball" menu is successfully displayed as disabled after focusing the webpage, developer tools buttons and inside the panel's content.
It seems that this is more general.It can be reproduced with other developer tools buttons (like RDM).

Mozregression pointed out Bug 1444793.

Last good revision: c46d66fe3cd48024c19495885c8381fef7a7819c
First bad revision: 8b4050603e3d62de4d95b82681a1acc3717f2487

Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c46d66fe3cd48024c19495885c8381fef7a7819c&tochange=8b4050603e3d62de4d95b82681a1acc3717f2487

Mantaroh, can you please have a look into this?

Thanks!
Blocks: 1444793
No longer blocks: 1468999
Flags: needinfo?(mantaroh)
Keywords: regression
That's just the focus style. The menu button is still focused. I'm not sure how we want to represent that.
I suppose the question is: should the button actually steal the focus? 

Right now for instance the button for the iframe selector does not steal the focus, but the meatball one does.
If you are on the Console, with focus in the console input, you can use the iframe picker, the focus will still be in the console after your action.
Severity: trivial → normal
Priority: -- → P5
(In reply to Julian Descottes [:jdescottes][:julian] from comment #3)
> I suppose the question is: should the button actually steal the focus? 

Oh, good point. I always assumed clicking equals focusing but I guess it doesn't have to.
(In reply to Brian Birtles (:birtles) from comment #4)
> (In reply to Julian Descottes [:jdescottes][:julian] from comment #3)
> > I suppose the question is: should the button actually steal the focus? 
> 
> Oh, good point. I always assumed clicking equals focusing but I guess it
> doesn't have to.

Thanks, Brian, Julian.

I think that macOS doesn't steal the focus when clicking the iframe selector. However, Windows and GTK will steal the focus. 
I added the element.focus() code into meatball button due to the reason of platform difference. (macOS can't handle the key event listener of metaball menu if the metaball button didn't have the focus.)

Maybe, iframe selector can't use the Alt + down key event listener of this button.
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(mantaroh)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: