Issue metadata
Sign in to add a comment
|
Version 53 introduces background image regression
Reported by
bkl...@rksystems.com,
Sep 16 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.113 Safari/537.36 Example URL: https://ebms.nci.nih.gov/docs/post [password protected site to which I am not authorized to give out credentials] Steps to reproduce the problem: 1. Click on checkbox 2. Observe mismatch between background image Chrome thinks it's displaying and the background image actually displayed (see attached screen shot) What is the expected behavior? Browser shows background image for ... input.class-name:checked + label selector What went wrong? The developer information makes it clear that Chrome thinks it is rendering the page with the correct background image, but the page itself is showing a different background image. The attached screen shot says it all. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? Yes It always worked until Chrome updated itself to version 53, and it still works in every other browser Does this work in other browsers? Yes Chrome version: 53.0.2785.113 Channel: n/a OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0 First of all, there appears to be some confusion about the appropriate place to report a bug in Chrome. I clicked on the "Report an issue" button on chrome://help/ and a popup appeared which I filled out and submitted. That ended up on a forum (https://productforums.google.com/forum/?utm_medium=email&utm_source=footer#!msg/chrome/tN7A_6Dj4jg/FDKP1SuTAQAJ) where the community specialist kept insisting that I had submitted my report to the wrong forum (even though I see that this bug tracker itself has instructions saying that the forum I had originally posted the report is an appropriate venue for bug reports). I will try to come up with a repro case I can provide which avoids the need to connect to the private site on which we ran into the bug, and I will also try to obtain permission for the Chrome developers to connect to that protected site, but I'm not optimistic that we'll get that. In the meantime, you at least have sufficient evidence that there is in fact a bug in Chrome, given that the page is rendered correctly in every other browser (and was rendered correctly in Chrome until version 53), and Chrome itself thinks it is rendering a different background image than the one we see on the page. I'll be happy to answer any questions you have which I haven't already addressed here. Thanks.
,
Sep 19 2016
All: the problem (see cmt#1) persists in 54.0.2840.27 (beta) and canary 55.0.2864.0 (for Win10 desktop Chrome). Bob - these kind of java script errors tend to effect a lot of users in different situations, and often (may) get fixed within a few (4-6) weeks. Resolution will probably appear in beta first. later, Larry
,
Sep 20 2016
,
Sep 22 2016
bkline@: Could you please check the URL in C#1 as I am getting 'This site can’t be reached' when trying to access. Please update the thread with the working URL to bisect this issue. Thank you!
,
Sep 22 2016
The URL in comment 1 is correct, and as far as I can tell the URL is working fine and should be reachable from anywhere. There was a restart of the machine following some kernel updates at 4:30 EDT yesterday afternoon, introducing a few seconds of down time, but it seems unlikely from the time stamp of your comment that there was any connection between that and the problem you ran into. Please try clicking on the link directly from the comment to rule out errors in transcription of the URL. If the failure to connect persists, could you post a screen shot of the browser including the address bar, as well as the IP from which you're trying to connect? Thanks!
,
Sep 22 2016
Just out of curiosity, why would the status of the ticket still be Unconfirmed, given Larry's comment?
,
Sep 22 2016
I have installed another instance of the repro case on another server, hosted elsewhere, in case you're still having difficulty finding home.rksystems.com: http://rksystems.com/issue647780/index.php?q=repro Please confirm whether you can reach at least one of the repro URLs. Thanks.
,
Sep 22 2016
Here's a third instance (completely different hosting and DNS): http://uuca-music.org/issue647780/repro Can you get to any of these? I have confirmed that they're all accessible from lots of different networks. Thanks.
,
Sep 22 2016
Thanks for the URLs. Able to reproduce this issue on the latest canary(55.0.2868.0) and the latest stable(53.0.2785.116) on Windows-10, Mac OS 10.11.6 and Linux Ubuntu 14.04. This is a regression issue broken in M-53. Last good build: 53.0.2782.0 First bad build: 53.0.2784.0(No 53.0.2783.0 for Windows) Changelog: https://chromium.googlesource.com/chromium/src/+log/07a50f9a656f418b9ec2070fcc015cfd36cb9c3b..159d66f36734dab8cfd79c6ae788b94fca8a213a Not sure though but mahesh.ma@ could this be related to https://codereview.chromium.org/2104883002. Please help in re-assigning if the change is unrelated. Thank you!
,
Sep 22 2016
I think this is more likely rune@'s change with the sibling selectors.
,
Sep 22 2016
Also confirmed (bad) for 53.0.2785.124 on Android 6.0.1;SM-N920V Build/MMB29K.
,
Sep 23 2016
,
Sep 23 2016
,
Sep 23 2016
I'm impressed! You guys don't let any grass grow under your feet. Thanks for for the quick response. :-)
,
Sep 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6e86e7b3077b12108d3a231e75b2da7e3529d04e commit 6e86e7b3077b12108d3a231e75b2da7e3529d04e Author: rune <rune@opera.com> Date: Tue Sep 27 06:09:49 2016 Missing sibling invalidation across removed element. When removing B from siblings A B C, we scheduled invalidations for features of A requiring two adjacent combinators to schedule an invalidation at all. That is fine for rules already affecting C, but for rules kicking in after B is removed, a single combinator is enough. For instance ".a + .c". R=ericwilligers@chromium.org BUG= 647780 Review-Url: https://codereview.chromium.org/2362463004 Cr-Commit-Position: refs/heads/master@{#421124} [modify] https://crrev.com/6e86e7b3077b12108d3a231e75b2da7e3529d04e/third_party/WebKit/LayoutTests/fast/css/invalidation/sibling-mutation-min-direct.html [modify] https://crrev.com/6e86e7b3077b12108d3a231e75b2da7e3529d04e/third_party/WebKit/Source/core/dom/StyleEngine.cpp
,
Sep 27 2016
,
Sep 27 2016
Approving for M54 for today's Beta
,
Sep 27 2016
BETA RC cut is scheduled at 4.00 PM PST today ( 09/27), so please merge your change to M54 (branch: 2840) ASAP.
,
Sep 28 2016
Verified the fix on the latest canary(55.0.2874.0) on Windows-10. 55.0.2874.0 for Mac and Linux are not available to test and confirm the same due to compile failure. Adding the verified label as per the verification on Windows 10.
,
Sep 28 2016
,
Sep 28 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e642be85ee4f7a28fb3ee6e652abdb5b8f149269 commit e642be85ee4f7a28fb3ee6e652abdb5b8f149269 Author: Rune Lillesveen <rune@opera.com> Date: Wed Sep 28 16:00:49 2016 Missing sibling invalidation across removed element. When removing B from siblings A B C, we scheduled invalidations for features of A requiring two adjacent combinators to schedule an invalidation at all. That is fine for rules already affecting C, but for rules kicking in after B is removed, a single combinator is enough. For instance ".a + .c". R=ericwilligers@chromium.org BUG= 647780 Review-Url: https://codereview.chromium.org/2362463004 Cr-Commit-Position: refs/heads/master@{#421124} (cherry picked from commit 6e86e7b3077b12108d3a231e75b2da7e3529d04e) Review URL: https://codereview.chromium.org/2375103002 . Cr-Commit-Position: refs/branch-heads/2840@{#562} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/e642be85ee4f7a28fb3ee6e652abdb5b8f149269/third_party/WebKit/LayoutTests/fast/css/invalidation/sibling-mutation-min-direct.html [modify] https://crrev.com/e642be85ee4f7a28fb3ee6e652abdb5b8f149269/third_party/WebKit/Source/core/dom/StyleEngine.cpp
,
Sep 28 2016
,
Oct 5 2016
Tested the issue on Chrome Beta# 54.0.2840.50 on Windows, Mac and Linux and is working without any rendering issue. Hence adding TE-Verified Labels. Attaching screenshot for reference. Thank You.
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/e642be85ee4f7a28fb3ee6e652abdb5b8f149269 commit e642be85ee4f7a28fb3ee6e652abdb5b8f149269 Author: Rune Lillesveen <rune@opera.com> Date: Wed Sep 28 16:00:49 2016 Missing sibling invalidation across removed element. When removing B from siblings A B C, we scheduled invalidations for features of A requiring two adjacent combinators to schedule an invalidation at all. That is fine for rules already affecting C, but for rules kicking in after B is removed, a single combinator is enough. For instance ".a + .c". R=ericwilligers@chromium.org BUG= 647780 Review-Url: https://codereview.chromium.org/2362463004 Cr-Commit-Position: refs/heads/master@{#421124} (cherry picked from commit 6e86e7b3077b12108d3a231e75b2da7e3529d04e) Review URL: https://codereview.chromium.org/2375103002 . Cr-Commit-Position: refs/branch-heads/2840@{#562} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/e642be85ee4f7a28fb3ee6e652abdb5b8f149269/third_party/WebKit/LayoutTests/fast/css/invalidation/sibling-mutation-min-direct.html [modify] https://crrev.com/e642be85ee4f7a28fb3ee6e652abdb5b8f149269/third_party/WebKit/Source/core/dom/StyleEngine.cpp |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by bkl...@rksystems.com
, Sep 17 2016