User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:66.0) Gecko/20100101 Firefox/66.0 Steps to reproduce: Have a lot of tabs open, making the tabs take their minimum horizontal space. Then try to switch to a tab that is currently outputting audio by clicking between the favicon and the speaker icon. Actual results: Firefox switches to the tab and mutes the tab at the same time. The speaker icon sits below the mouse cursor now, as the close tab icon has come into view. (It is almost as if the icon moved position before the click was fully handled by the browser. Thus making me click the newly repositioned speaker icon.) Expected results: Firefox switches to the tab with no further action taken.

[Tracking Requested - why for this release]: incorrect click event will fire on the tab mute buttun Regression on Nightly66. Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=f6eebcc14c22762f521fb567a9588963b8720592&tochange=61570c16c2d564c24fab36713fb169c4144453e9 Suspect: 36b949bef798 Olli Pettay — Bug 1089326, make <button> hit testing similar to other elements which may have some content, and for click target find the common (interactive) ancestor, r=masayuki :smaug Your patch seems to cause the regression. Can you please look into this?

Ah, yes, if one clicks on the tab icon, switching works ok, but if one clicks on top of the text, when mouseup happens, audio icon has moved already to cover that so that tab close button can be shown... And possible reason for this behavior is that before the change we weren't probably dispatching click at all, since mousedown/up were happening on different elements, but now click target is the common ancestor.

Oh, https://searchfox.org/mozilla-central/rev/1a4a7745fd4a14402a0de0e9abc040724d4fcf8f/browser/base/content/tabbrowser.xml#2415,2433-2440 is weird. click handler explicitly checking whether mouse is over playing icon and not relying on DOM event dispatch. jaws, you might recall the reasoning for that implementation strategy. (hg blame is a bit hard to follow here, for some reason)

_overPlayingIcon was introduced by https://searchfox.org/mozilla-central/diff/88b20b1817041b493fda7ebbf10078e0fed2e44c/browser/base/content/tabbrowser.xml as a way to update the tooltip for the tab. I agree it was probably not necessary to use _overPlayingIcon for the click event handler. My guess is that someone saw the member variable and thought it was necessary to use.

New regression, tracking just to make sure it lands at this point.

Pushed by jwein@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e1faf5fa77a6 Use originalTarget instead of relying on _overPlayingIcon where possible. r=dao