Issue metadata
Sign in to add a comment
|
subpixel aa on "Pop-up blocked" message text with transparent layer bg
Reported by
avsha...@etouch.net,
Mar 27 2017
|
||||||||||||||||||||||
Issue descriptionChrome Version : 57.0.2987.129 (Official Build) b551bbe0ceab0a0dc2248cde62f8e4c197bad4db-refs/branch-heads/2987@{#880} 32/64 bit OS : Windows (7,8,10), Linux (14.04 LTS) Test URL : http://www.popuptest.com/popuptest1.html What steps will reproduce the problem? 1. Launch chrome and navigate to above test URL. (Kindly wait until "Pop-up blocked" message vanishes from omnibox) 2. Press F6 key and the hit TAB key such that focus move on 'Pop-Up' icon in omnibox. 3. Now hit 'ENTER' key twice and reload the page using 'F5' key, observe the "Pop-up blocked" message in omnibox. Actual : "Pop-up blocked" message text appears weird (extra bold font) after reloading the page. Expected : Instead, "Pop-up blocked" message text should be seen properly and font style of message should not be BOLD. This is a regression issue broken in ‘M-53’, below is the Manual Regression range and will soon update other info. Good build : 53.0.2784.0 Bad build : 53.0.2785.0 Note : Above issue is only reproducible on Windows(7,8,10) & Linux(14.04 LTS) OS and it is working fine in Mac (10.11.6, 10.12.1, 10.12) OS.
,
Mar 27 2017
Using the per-revision bisect providing the bisect results, Good build: 53.0.2784.0 (Revision:403038). Bad build: 53.0.2785.0 (Revision:403382). You are probably looking for a change made after 403169 (known good), but no later than 403170 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/e959e110424ef144189fa2046e046f6a5003d5ee..fc47fab1198649e7e3c7e447db6453ae7f2ba612 @estade: 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. Thank You.
,
Mar 27 2017
,
Mar 28 2017
After some investigation I'm pretty sure this is related to bug 663335 When we set the ripple to deactivated on a focused button, then the button loses focus, we never destroy/remove the ink drop layer because of the early return in InkDropImpl::AnimationEnded.
,
Mar 28 2017
,
Apr 11 2017
Friendly ping!! bruthig@, Still we are able to reproduce the issue on latest stable 57.0.2987.133.Could you please check the issue & update the thread accordingly. Thank you!!
,
Apr 12 2017
+ mohsen@, any chance you have some time to look into this? + spqchan@, does your current, or planned, work affect this button? I looked briefly but I think we may have 2 issues here: 1. The InkDrop is possibly not destroyed under some conditions. (As noted in Comment 4) 2. The 'Popup was blocked' button doesn't properly configure it's label to accommodate the InkDrop. Presumably the button _should_ show the ink drop if necessary while the text is visible. However, this does not appear to be the case. IMO 1. & 2. should be investigated and both fixed if true. Pseudocode unit test to repro the persisting InkDrop: 1. Configure a button with HIDE_ON_RIPPLE AutoHighlight Mode 2. Focus the button 3. Animate ripple to ACTIVATED 4. Animate ripple to DEACTIVATED 5. Unfocus the button 6. Verify the InkDrop has been destroyed and the button Layers have been collapsed. This issue might be related to Issue 704473 .
,
Apr 12 2017
Yes, my current work affects this button (ContentSettingImageView). It's possible that it fixed the issue, but I'll have to test more to be sure
,
Jun 13 2017
I'm unable to repro this on ToT Linux chrome build - cd4cfecb68b303ff494ba5c5902eb0629f1c5c45 and on 60.0.3112.4 canary-channel veyron_minnie. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ranjitkan@chromium.org
, Mar 27 2017Status: Untriaged (was: Unconfirmed)