Regression: Weird behavior of 'Pricezilla' extension welcome page is seen after giving Print.
Reported by
dmascare...@etouch.net,
Jan 2 2017
|
|||||
Issue descriptionChrome Version:57.0.2969.0 (Official Build) 9d1a05815549df9a90f4383645564d7160850901-refs/heads/master@{#441040} OS:Mac(10.12.1, 10.11.6, 10.12), Windows(7,8,10), Linux (14.04 LTS) Test url: https://chrome.google.com/webstore/detail/pricezilla/cklfdldkepnphkeekfkeppdkblfhcaen?utm_source=chrome-ntp-icon What steps will reproduce the problem? 1. Launch chrome and navigate to above test url. 2. Click on 'Add to chrome' button such that 'The extension has been successfully added' page is seen. 3. Press 'Ctrl+P' and click on 'Cancel' button, observe the page. Actual: Weird behavior of 'Pricezilla' extensions welcome page is seen after giving Print. Expected: Page should be seen properly after step 3. This is regression issue, broken in 'M 57' and below is manual bisect info: Good build:57.0.2953.0 Bad build:57.0.2955.0
,
Jan 2 2017
I don't think this bisect is correct. I manually reverted cathiechen's change and the bug still reproduces. I did a bisect and got a slightly different range: https://chromium.googlesource.com/chromium/src/+log/29942ba33818a9db2fc90a441b80d56cbdbc1f1f..bf9901feb0c46cefbd5e7af40fe252a6a92d52cb I think https://chromium.googlesource.com/chromium/src/+/90d4ea3d543f0031769b3aacac2d3e084b95fb7d is a more likely cause. test team, can you re-bisect this to see if it is rune's change? If it turns out to be the other change, please assign to Rune. Attached is a minimized testcase. Steps to reproduce: 1) Open testcase 2) Open the print dialog 3) Cancel the print dialog 4) The "extension added" text should not move.
,
Jan 3 2017
With response to comment #2: Below is narrow bisect info: https://chromium.googlesource.com/chromium/src/+log/6a87148dbee3293f14f151d94b760798e1768068..90d4ea3d543f0031769b3aacac2d3e084b95fb7d?pretty=fuller&n=100 Suspecting: r439092 ? Could you please help to reassign this bug if your change is not the cause for this issue
,
Jan 3 2017
Yes, this is mine. Adding an @media print { * { color:pink } } to extensionadded.html makes it work. This is a missing invalidation for the UA print stylesheet. Thanks for the test reduction.
,
Jan 3 2017
Reduced case:
<!DOCTYPE html>
<style>
div {
width: 50vw;
height: 100px;
background: orange;
}
</style>
<div></div>
,
Jan 5 2017
,
Jan 5 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/010fc15a8b14c1d9b7a651096cdad195c2532346 commit 010fc15a8b14c1d9b7a651096cdad195c2532346 Author: rune <rune@opera.com> Date: Thu Jan 05 12:54:34 2017 Need to clear viewport dependent units when switching print mode. Switching between print and screen changes the size of the initial containing block. Viewport dependent lengths need to be recalculated and the cache for matched properties cleared. Normally, notifyResizeForViewportUnits() is called from performPreLayoutTasks when the initial containing block size changes. That does not happen when laying out for printing and going back to screen layout. We skip setting m_lastLayoutSize in sendResizeEventIfNeeded. We probably do that to avoid triggering resize events going back and forth between the print (preview) size. Make sure we clear the matched properties cache from StyleResolver when updating the media type. R=mstensho@opera.com BUG= 677799 Review-Url: https://codereview.chromium.org/2613733003 Cr-Commit-Position: refs/heads/master@{#441642} [modify] https://crrev.com/010fc15a8b14c1d9b7a651096cdad195c2532346/third_party/WebKit/Source/core/css/resolver/StyleResolver.cpp [modify] https://crrev.com/010fc15a8b14c1d9b7a651096cdad195c2532346/third_party/WebKit/Source/web/tests/WebViewTest.cpp
,
Jan 5 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by hdodda@chromium.org
, Jan 2 2017Labels: hasbisect-per-revision ReleaseBlock-Stable
Owner: pdr@chromium.org
Status: Assigned (was: Unconfirmed)