[MdRefresh] Tab Favicon is pushed to the right during mouse hover, when the Speaker icon is visible on background tabs |
|||||||||
Issue descriptionChrome Version: Canary Version 69.0.3464.0 OS: macOS 10.13 but probably OS=All What steps will reproduce the problem? (1) Play a YouTube video, so that the Speaker icon appears on the tab. (2) Open a second tab. (3) Now hover over the YouTube Tab, which is on the background. What is the expected result? The favicon should not be pushed to the right. What happens instead? The favicon is pushed to the right during mouse hover. A screencast is attached. Thanks for looking into this issue, Mehmet
,
Jun 18 2018
This is a bug in the logic about when to add extra padding.
,
Jun 18 2018
Issue 853623 has been merged into this issue.
,
Jun 21 2018
Blocked on close button decision
,
Jun 21 2018
I don't know if it is, actually -- I think we may have this bug even if background tabs always show close buttons.
,
Jun 25 2018
Triage: Upgrading to P1 - Flicker or movement now meets the P1 bar.
,
Jun 28 2018
kylixrd: Can this be load balanced to bsep?
,
Jun 28 2018
Sure. Done.
,
Jul 2
> I don't know if it is, actually -- I think we may have this bug even if background tabs always show close buttons. Yes, this bug is also present even if background tabs always show close buttons now. The only difference is, that the favicon is pushed a little bit to the right when the speaker and stays then there. Attached a screencast.
,
Jul 2
Not P1 anymore, but I'll look at it.
,
Jul 2
FWIW, the code in this function (that computes icon visibility) is so confused and cryptic compared to its original incarnation that what makes the most sense to me is to try to nuke the function and compute icon visibility on the fly during layout.
,
Jul 3
So this is not actually a Refresh regression, it reproduces in the old UI. That said, it's pretty obnoxious, so maybe I'll try and fix it anyway...
,
Jul 3
We likely regressed it during the Touchable refactoring, which seems to have introduced a couple bugs to this code. I suspect e.g. Chrome 61 wouldn't have this. Not 100% sure though.
,
Jul 3
The logic itself is pretty suspect; we just randomly add extra padding when all three icons are shown. I think it's supposed to be a proxy for "is there enough room to add the extra padding" but it needs to be redone.
,
Jul 3
The logic used to basically be, remove the extra padding at the same time the tab gets narrow enough to hide the close button. Somehow those two got a bit divorced. It's been tweaked a couple of times for different bug fixes, you'll want to look at the blame history to see which bugs people were attempting to fix, to make sure you don't repeat those (hopefully we added regression tests but who knows).
,
Jul 3
Apologies if I'm wrong but is issue 848438 the same as this?
,
Jul 3
Issue 848438 has been merged into this issue.
,
Jul 3
also it's not just the audio indicator that causes the favicon to twitch, the recording icon too (in the attached screenshot, I was leaving a voice message on WhatsApp)
,
Jul 11
Issue 862790 has been merged into this issue.
,
Jul 12
,
Jul 12
Triage: How's this going?
,
Jul 12
It's in review, but I'm making Bret's life hard*, so it's not landed yet. *About actual behavior, not just things like style or technical debt.
,
Jul 12
,
Jul 17
Issue 864626 has been merged into this issue.
,
Jul 17
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27 commit bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27 Author: Bret Sepulveda <bsep@chromium.org> Date: Tue Jul 17 22:10:09 2018 Increase size at which close buttons on inactive tabs disappear. This patch changes the size at which close buttons disappear from being approximately 48 dips of content area to being a fixed constant. As a first pass I've set the constant to 68 dips, which feels good to me. This patch also ties the logic for when to show extra left padding to the close button visibility, which addresses cases where the favicon would "twitch" due to the alert indicator appearing. Bug: 853788 , 863027 Change-Id: I681f8b7d530b192f2fd5943436ae16bd93f33fba Reviewed-on: https://chromium-review.googlesource.com/1125315 Reviewed-by: Peter Kasting <pkasting@chromium.org> Commit-Queue: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#575795} [modify] https://crrev.com/bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27/chrome/browser/ui/views/tabs/tab.cc [modify] https://crrev.com/bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27/chrome/browser/ui/views/tabs/tab.h [modify] https://crrev.com/bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27/chrome/browser/ui/views/tabs/tab_strip_unittest.cc [modify] https://crrev.com/bb53e26734e70a1f28d0d1d3fe16f2a7eaf5ca27/chrome/browser/ui/views/tabs/tab_unittest.cc
,
Jul 17
|
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by robliao@chromium.org
, Jun 18 2018Owner: kylixrd@chromium.org
Status: Assigned (was: Untriaged)