Closed Bug 1514613 Opened Last year Closed Last year

Clicking tab will mute audio


(Firefox :: Tabbed Browser, defect, P1)

66 Branch



Firefox 66
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- unaffected
firefox65 --- unaffected
firefox66 + verified


(Reporter: martijn.personal+bugzilla, Assigned: jaws)



(Keywords: regression)


(2 files)

Attached image click.png
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:

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

Your patch seems to cause the regression. Can you please look into this?
Blocks: 1089326
Component: Tabbed Browser → DOM: Events
Ever confirmed: true
Flags: needinfo?(bugs)
Keywords: regression
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,,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)
Flags: needinfo?(jaws)
_overPlayingIcon was introduced by 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.
Flags: needinfo?(jaws)
Assignee: nobody → jaws
Flags: needinfo?(bugs)
Priority: -- → P1
Duplicate of this bug: 1515047
New regression, tracking just to make sure it lands at this point.
Flags: qe-verify+
Duplicate of this bug: 1514358

Review ping?

Flags: needinfo?(dao+bmo)
Flags: needinfo?(dao+bmo)
Pushed by
Use originalTarget instead of relying on _overPlayingIcon where possible. r=dao
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → Firefox 66

Verified on Nightly 66(20190109092644), that the issue is not reproducible with STR from Comment 0.

Flags: qe-verify+
Depends on: 1530367
You need to log in before you can comment on or make changes to this bug.