Chrome's letter is 555px wide, but when determining number of pages, it honors a media query for 645 or greater px
Reported by
beaumier...@co.brown.wi.us,
Oct 27 2017
|
|||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36 Steps to reproduce the problem: 1. Try to print the attached page. What is the expected behavior? Because of Issue 489521, Chrome thinks that US letter is 555px wide in portrait and and 735px wide in landscape. I expect to get a complete printout in both orientations with the landscape orientation putting column 4 of the table on one line. What went wrong? Printing in portrait is cut off. Since this does not happen if I eliminate the @media print and (min-width: 645px) query, I presume that it's honoring the media query when calculating the number of required pages although it applies only to widths of at least 645px. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 62.0.3202.62 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version:
,
Oct 30 2017
Is CSS the right component for media queries?
,
Oct 31 2017
,
Oct 31 2017
The bug here is that when using the provided test file, the end of the print is cut off in portrait mode. Instead of getting all the way to the end of the names with 'Z', it gets cut off at 'M'. To see this, you need to scroll to the end of the print preview. Note that both Chrome and Firefox produce a 7 page document in portrait mode. I suspect something might be going on with the text of one of the columns going over 2 lines in Chrome, but not in Firefox.
,
Oct 31 2017
Firefox is honoring the media query by putting "Rockland Township" on one line because, to Firefox, a US Letter portrait page is wider than 645px. Chrome thinks a portrait page is only 555px but seems to be honoring my 645px media query when determining the number of pages to spit out.
,
Nov 1 2017
Able to reproduce the issue on windows 10 , ubuntu 14.04 and Mac OS 10.12.6 using chrome M64 #64.0.3255.0 and M62 #62.0.3202.75 with the steps mentioned in comment #4. This is a regression issue broken in M54 . Using the per-revision bisect providing the bisect results, Good build: 54.0.2820.0(Revision: 409955). Bad build: 54.0.2821.0 (Revision: 410228). You are probably looking for a change made after 410169 (known good), but no later than 410181 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/a9094bdb2cda679e8bf3a5b43b27c12efa975d3c..fc1140de1b4563d3d890512e4a4f5f6481dddd0f Possible Suspect : https://chromium.googlesource.com/chromium/src/+/a7760a764855fb5678f7e5e88e11b834416ffbb7 From the CL above, assigning the issue to the concern owner @nainar- Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Thanks!
,
Nov 1 2017
,
Nov 1 2017
My CL was reverted after landing.
,
Nov 2 2017
Regressed in M54, so setting Pri-2.
,
Nov 2 2017
@nainar - can you please give the revision number that your patch was reverted on so a new bisect can be started between that revision and m62. Please also set Needs-Bisect and remove yourself as owner. Thanks!
,
Nov 7 2017
Well loos like I am a silly goose. The patch was just reverted here: https://chromium-review.googlesource.com/c/chromium/src/+/749949/. So marking myself as Owner to test this issue once it is on Canary.
,
Nov 10 2017
,
Nov 10 2017
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by manoranj...@chromium.org
, Oct 27 2017