New issue
Advanced search Search tips

Issue 822250 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 10
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug



Sign in to add a comment

When printing a slippy map rendered with Leaflet part of the map is shown in error on following page

Reported by sethpken...@gmail.com, Mar 15 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.162 Safari/537.36

Steps to reproduce the problem:
1. Open test code: https://plnkr.co/edit/IBnjyibDKg87DEXjstWL?p=preview
2. Open in windowed mode by clicking the blue expand button at the top right of the plunker
3. Zoom in on the map a bit and pan to the north by clicking within the window and dragging down. (The problem is created when tiles rendered and hidden around the edge are inexplicably shown during print mode. 
4. Print the test window.

What is the expected behavior?
A two page print job with a map on the first page and text on the second.

What went wrong?
A patch of the map appears at the top of the second page and obscures some of the content there.

Did this work before? No 

Chrome version: 65.0.3325.162  Channel: stable
OS Version: 10.0
Flash Version: 29.0.0.113

A bug report has been filed with the makers of the map viewer as well(https://github.com/Leaflet/Leaflet/issues/5904#issuecomment-343509678), but the problem is only seen in Chrome.
 
chrome_leaflet_printing_bug.PNG
148 KB View Download
Labels: Needs-Triage-M65
Cc: thestig@chromium.org
Components: -Blink Internals>Printing
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable RegressedIn-61 Triaged-ET M-65 M-66 FoundIn-66 Target-66 Target-65 FoundIn-65 hasbisect OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: nick@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 14.04 using chrome reported version #65.0.3325.162 but the same is not reproducible in the latest canary #67.0.3371.0.

Reverse Bisect Information:
===========================
Good build: 67.0.3367.0
Bad Build : 67.0.3366.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/abc55490658e0ec0bf2be019449b7248b923ce90..cbbf6d7ba09944355e52c1cad494d8963398dc62

From the above change log suspecting below change
Change-Id: I2225ded078a14b2ffcf6643e483ff995c48cb66a
Reviewed-on: https://chromium-review.googlesource.com/947398

nick@ - Could you please check and merge the fix to M-65 if it is a valid candidate.
ccing thestig@(reviewer)for further inputs if it is related to printing?
Adding RBS label for M-65 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!
Labels: -ReleaseBlock-Stable
This isn't a regression since I see similar behavior on Chrome version 64 as well hence doesn't warrants for M65 stable blocker.I am removing release block stable. 


Comment 4 by nick@chromium.org, Mar 16 2018

Owner: weili@chromium.org
The 'bad' cases aren't 100% repro, since the "scroll north a bit" step seems to requires a bit of luck in tile alignment. So bisect results are a little suspect. Having said htat, I re-did the bisect with --site-per-process enabled, and found the following revision range 

https://chromium.googlesource.com/chromium/src/+log/7f95c8453a369c61e3c2bf23a7fb7c8ea60b1e6b..bc2e913bd7fbf429655bf3f950f33ddfd9a4437c

Included in that is weili's "use pdf compositor service when site isolation is enabled". The earlier bisect result may just have been picking up on versions where site isolation field trials are active. HOWEVER, I wasn't able to repro at TOT with site isolation disabled (--disable-site-isolation-trials), so something doesn't quite add up. 

Thus, I think this may simply be a case where our behavior improves with the pdf compositor service. Assigning to weili to triage further. PDF compositor service may not be on by default for all users in M66, so we should check whether the bug appears there.

Comment 5 by nick@chromium.org, Mar 16 2018

Labels: -Type-Bug-Regression Type-Bug

Comment 6 by weili@chromium.org, Apr 12 2018

This bug should not be related pdf compositor service as it happens with compositor service was enabled. I checked Chrome Beta 66.0.3359.81, Chrome Canary 67.0.3394.0, this doesn't happen any more. Pls check whether this is fixed.
Status: Fixed (was: Assigned)
I tried on Chrome Canary on Windows and Mac, top of tree on all platforms again. I could no longer reproduce the problem. Will mark this as fixed. Pls reopen it if you find otherwise.
Labels: TE-Verified-69.0.3489.0 TE-Verified-M69
Verified the fix on Mac 10.13.3, Win-10 and Ubuntu 17.10 using latest chrome version #69.0.3489.0 as per the comment #0.
Attaching screen cast for reference.
Observed a two page print job with a map on the first page and text on the second as expected.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!
822250.mp4
2.2 MB View Download

Sign in to add a comment