Using the per-revision bisect providing the bisect results,

Good build: 55.0.2875.0 (Revision: 421703).
Bad build: 55.0.2876.0 (Revision: 421986).

You are probably looking for a change made after 421841 (known good), but no later than 421842 (first known bad).

CHANGE-LOG URL:
-------------------------------

https://chromium.googlesource.com/chromium/src/+log/25f4d7c50e3217446d49744876bba37754d3c08a..4f480f4f6f1596f54d6de2c149fafbd72ed33030

From the CL above, assigning the issue to the concern owner

@estark:

Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Review-Url: https://codereview.chromium.org/2366943003

Note : Not Able to reproduce the issue in linux ubuntu 14.04.

Adding RB label as this is a recent regression

I don't think this is related to my change. Is it possible that the reproduction is flaky and so the bisect returned incorrect results?

Re bisected it and below is the change log obtained

https://chromium.googlesource.com/chromium/src/+log/bd027238e7f3d3c8096c1a62e9063d8cbf5d8a80..902a3d6303dfbfd49a24173777afcb4b70234a17

@ mustaq: Request you to please take a look into it. Please help us to find an owner if not with respect to your change.

Change URL: https://chromium.googlesource.com/chromium/src/+/902a3d6303dfbfd49a24173777afcb4b70234a17
Review-Url: https://codereview.chromium.org/2375493005

Issue is marked with a Stable blocker and M55 is approaching Beta soon.

Thanks.!

The bisect seems wrong. I tried to repro on Chrome 55.0.2883.18 (current Linux dev) build which includes my CL, and the page works perfectly. Will bisect again.

Also tried on Chrome 56.0.2889.0 canary on Windows. Couldn't repro.

Also couldn't repro on 56.0.2891.0 on Win 7.

vkupte@etouch.net: Please mention the Chrome version & OS where you recorded the repro.

I am able to reproduce the issue on latest Chrome beta(55.0.2883.21),Dev(56.0.2896.3) and Canary(56.0.2897.0), Also on Chrome version 55.0.2883.19 on my Windows 7 machine.

I see that sometimes it works but when it works in Zoom instate try to mute the and then zoom out from 250% to 100%(default) and able to reproduce.

Please have a fix (baked/verified in canary and merge M55 branch 2883) as this marked as M55 stable blocker.

Thank you.

**** Bulk edit -  please ignore if not applicable ****

A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

After many attempts, I was able to repro the problem only once on Chrome beta (55.0.2883.21) on Win7. Not sure what sequence of actions reproduces it. I saw it only once with this sequence (out of my 10+ attempts):
- Go to http://tidbits.com/podcasts/14397.m4a
- Click mute.
- Zoom the page to 250%.
- Click unmute.
- Unzoom the page to default (100%).
- Now clicking on mute button is unresponsive.

Given the hardness to reproduce, I think removing the RB-stable label makes sense. But this should still be a Pri-1.

Confirmed that this is not a regression: I was able to repro on Chrome 54.0.2840.71 on Linux. Here are the exact steps that works *some of the time*:
- With default (100%) zooming, go to http://tidbits.com/podcasts/14397.m4a.
- Click "mute".
- Move the mouse far away from the widget.
- Zoom to 250%.
- Now clicking the "mute" button may not work---I had it ~20% of my attempts.

It is clear that in step 3 in my last post, the mouse has to move rightward far enough so that the zoomed widget can't "catch" it. Looks like an issue with the audio widget.

Someone familiar with the audio widget should take a look.

I can't reproduce even with steps from comment 14. I assume it was fixed somewhere in the past 10 months :)