Closed Bug 1514613 Opened Last year Closed Last year
Clicking tab will mute audio
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.
Component: Untriaged → Tabbed Browser
[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?
Status: UNCONFIRMED → NEW
Component: Tabbed Browser → DOM: Events
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
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.
Component: DOM: Events → Tabbed Browser
Product: Core → Firefox
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.
Assignee: nobody → jaws
Status: NEW → ASSIGNED
New regression, tracking just to make sure it lands at this point.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e1faf5fa77a6 Use originalTarget instead of relying on _overPlayingIcon where possible. r=dao
You need to log in before you can comment on or make changes to this bug.