Closed Bug 1538049 Opened 7 months ago Closed 5 months ago

Clicking on the left side of the minimize button close the window on macOS

Categories

(Firefox :: Theme, defect, P3)

65 Branch
Desktop
macOS
defect
Points:
2

Tracking

()

VERIFIED FIXED
Firefox 68
Iteration:
68.4 - Apr 29 - May 12
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 --- verified

People

(Reporter: karlcow, Assigned: dao)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Tested on Firefox Nightly 68.0a1 (2019-03-20) (64-bit)
with macOS 10.14.3 (18D109)

I can reproduce this report by a user on twitter.
https://twitter.com/AxelFavry/status/1108706032283516929

The cursor needs to be just beside the minimize button on the left side. There is a tiny range for it to happen but it's happening.

OS: Unspecified → macOS
Hardware: Unspecified → Desktop
Component: General → Toolbars and Customization

Times, can you find when this regressed?

Flags: needinfo?(timea.zsoldos)

Fwiw - I think this is more of a Widget :: Cocoa thing, from what I can tell from https://searchfox.org/mozilla-central/rev/56705678f5fc363be5e0237e1686f619b0d23009/widget/cocoa/nsNativeThemeCocoa.mm#392-413.

Component: Toolbars and Customization → Widget: Cocoa
Product: Firefox → Core
Priority: -- → P3

Huh, it looks like we have two sets of buttons there: The native window buttons on top, with correct hover feedback, and XUL toolbarbuttons underneath. The XUL toolbarbuttons are misplaced and have the wrong size.

If you click in the gaps between the native buttons, you hit the XUL buttons. And the XUL close button happens to sit right at the left edge of the native minimize button.

Oh, the XUL buttons also have the wrong order.

Can we just set the XUL buttons to display:none on Mac?

Flags: needinfo?(mconley)

(In reply to Markus Stange [:mstange] from comment #4)

Oh, the XUL buttons also have the wrong order.

Can we just set the XUL buttons to display:none on Mac?

Yes, certainly - although that doesn't seem to help... if I manually remove those XUL nodes from the DOM, I'm still able to reproduce the issue.

Flags: needinfo?(mconley)

Manually removing the nodes solves the problem for me. Did you remove the nodes in the right window / document?

Perhaps I didn't. I trust you on this, so let's move this to Theme to get these things display: none'd on macOS.

Component: Widget: Cocoa → Theme
Product: Core → Firefox

Here is the regression range:

Last good revision: 1ab00b6e99fd65b651381c235f1ae95ed746e57a
First bad revision: e354a018b703c453e8afcda1f44f1d51456536f5
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1ab00b6e99fd65b651381c235f1ae95ed746e57a&tochange=e354a018b703c453e8afcda1f44f1d51456536f5

Has Regression Range: --- → yes
Flags: needinfo?(timea.zsoldos)

Mike it sounds like this is from bug 1356920.

Flags: needinfo?(mconley)
Regressed by: 1356920

Indeed, that certainly sounds plausible.

Flags: needinfo?(mconley)
Version: 68 Branch → 65 Branch
Assignee: nobody → dao+bmo
Status: NEW → ASSIGNED

Comment on attachment 9063998 [details]
Bug 1538049 - Fix broken .titlebar-button selector. r=ntim

Beta/Release Uplift Approval Request

  • User impact if declined: Glitch that's annoying to some users potentially causing data loss: https://twitter.com/AxelFavry/status/1108706032283516929
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See comment 0
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): one line CSS change fixing a broken selector
  • String changes made/needed: no
Attachment #9063998 - Flags: approval-mozilla-beta?
Flags: qe-verify+
Pushed by ntim.bugs@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/4f26cd2daf5c
Fix broken .titlebar-button selector. r=ntim
Status: ASSIGNED → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68

Comment on attachment 9063998 [details]
Bug 1538049 - Fix broken .titlebar-button selector. r=ntim

This is coming a bit late in the cycle as we will build RC today. Given that this is a P3, mac only and in the DOM inspector, I don't think the impact justifies an uplift in RC week, sorry.

Attachment #9063998 - Flags: approval-mozilla-beta? → approval-mozilla-beta-

(In reply to Pascal Chevrel:pascalc from comment #15)

Comment on attachment 9063998 [details]
Bug 1538049 - Fix broken .titlebar-button selector. r=ntim

This is coming a bit late in the cycle as we will build RC today. Given that this is a P3, mac only and in the DOM inspector, I don't think the impact justifies an uplift in RC week, sorry.

This is not only in the DOM inspector, this is in the browser window itself, but I guess the change can wait until the next release.

QA Whiteboard: [qa-triaged]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Firefox/68.0
Build ID: 20190513082256

Verified as fixed on the latest Nightly build on macOS 10.13.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Iteration: --- → 68.4 - Apr 29 - May 12
Points: --- → 2
You need to log in before you can comment on or make changes to this bug.