Issue metadata
Sign in to add a comment
|
"Mute Site" should be changed back to "mute tab"
Reported by
teo8...@gmail.com,
Mar 4 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36 Steps to reproduce the problem: I know this is by design but somebody has to realize this was a wrong decision that needs to be reverted. 1. right click on a tab What is the expected behavior? There used to be an item called "mute tab", that would mute that tab. That made sense. What went wrong? Now it's called "mute site" instead of "mute tab" and, consistently with its name, it will mute the site, not the tab, which means: 1. if you navigate to another site in the same tab, it will be unmuted. Wrong. 2. Even worse, if you open the same "site" (which apparently is a vague term that actually means the same DOMAIN) in another unrelated tab at a later time, it will be muted by default. and the worst of all: 3 - you can't have open several pages belonging to the same domain in different tabs and mute only one or only some of them. This is nonsensical and annoying. (3) alone should be enough to see how ridiculously wrong this new design is. Consider this trivial, common use case: - I open a youtube video on a tab - I open a different youtube video on a new tab. - Now I am interested in the latest I have opened, so I right-click on the old tab and mute it, obviously expecting to keep hearing the new one, but nope! they are both muted, and I can only unmute or mute both. Simply ridiculous, absolute nonsense. Not to mention EVERY other item in the tab right-click menu acts on the tab, while this one acts on the site: this is inconsistent, unexpected, and confusing. Did this work before? Yes very recently Chrome version: 64.0.3282.167 Channel: n/a OS Version: Flash Version: It's very worrying to see so many plain wrong design decision that have been taken recently in Chrome. Out of the top of my mind: explicit re-navigation to the current URL treated as a refresh, and now this. But there have been more. Has Google hired people from Apple or something?
,
Mar 5 2018
teo8976@ Thanks for the issue. Tested this issue on Mac OS 10.12.6, Windows 10 and Ubuntu 14.04 on the latest Canary 67.0.3361.0 and Stable 64.0.3282.186 able to reproduce the issue by following the steps mentioned above. Bisect Information: =================== Good Build: 64.0.3243.0 (Revision - 509636) Bad Build : 64.0.3244.0 (Revision - 509944) On executing the per-revision bisect script, below is the Changelog URL: https://chromium.googlesource.com/chromium/src/+log/e7fa637d7ac2f35b26ffc6c1d0b5cf443d6c787c..4bee58d8cc08debda0ea2d40a9d41a09b6f165a9 From the above Changelog, suspecting the below change: Reviewed-on: https://chromium-review.googlesource.com/722445 steimel@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable as this is a recent regression. Please feel free to remove it if it is not applicable. Thanks.
,
Mar 5 2018
Looks like an intended feature: issue 791896 , issue 816319 . The suggested "solution" is to use an extension to mute tabs individually. I think chromium team *must* provide an official extension for this purpose just like they did previously for "Go Back With Backspace" extension made in a similar situation: to improve one use case at the expense of another (also widely used) case.
,
Mar 6 2018
,
Mar 6 2018
,
Mar 6 2018
Issue 818517 has been merged into this issue.
,
Mar 6 2018
As this is regressed in M64 stable, we won't consider this as a blocker for M65. Pls let us know ASAP if there is any concern here. Thank you.
,
Mar 6 2018
,
Mar 7 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by sindhu.chelamcherla@chromium.org
, Mar 4 2018