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.

Times, can you find when this regressed?

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.

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?

(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.

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.

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

Mike it sounds like this is from bug 1356920.

Indeed, that certainly sounds plausible.

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

https://hg.mozilla.org/mozilla-central/rev/4f26cd2daf5c

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.

(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.

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.