Unwanted padding for table header only in first page
Reported by
sass...@gmail.com,
Apr 25 2017
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36 Steps to reproduce the problem: 1. Open this jsbin: https://jsbin.com/wivilex/edit?html,css,output 2. Press print button What is the expected behavior? Header in first page to have no padding nor margin like how it's rendered in second page. What went wrong? Seems like table in first page has padding-top or thead in first page has margin-top. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 58.0.3029.81 Channel: stable OS Version: OS X 10.12.4 Flash Version: It's so annoying that while old bugs with table rendering (specially related to headers and footers) aren't fixed yet, new versions of Chrome introduce new bugs and regressions. I'm trying to deliver a web application project which contains lots of report printings so I'm affected by these bugs. Would be great if you could add some tests to avoid these regressions.
,
Apr 26 2017
Able to reproduce the issue on windows 7,Ubuntu 14.04 and Mac 10.12.4 using chrome version 58.0.3029.81 and canary 60.0.3080.0. Observed the padding and margin till M50. M50 and prior versions not observed padding but could see the margin for table header. This is non regression issue from M30 old builds.Marking it as Untirgaed to get more inputs from dev team. Thanks,
,
Apr 26 2017
kavvaru, I don't understand your comment; "Observed the padding and margin till M50" contradicts "M50 and prior versions not observed padding". Could you clarify, with screenshots if necessary, what changed between 30 and 50, and what changed between 50 and 58? sassanh, maybe you know, did this work in any previous versions of chrome? And apologies for the regressions, please keep filing when you find them. We have a ton of tests but clearly not enough and when we do get a regression report we add a new test to ensure it doesn't regress again in the future.
,
Apr 26 2017
,
Apr 26 2017
I appreciate your responsible feedback. I understand avoiding bugs and regressions in a big project like Chrome is impossible. I'm sure my report pages didn't have this extra padding in first page till ~54. But if kavvaru tested this same jsbin in Chrome 54 and have seen the extra padding then I doubt maybe something else was avoiding the extra padding though the padding showed up without changing anything so if kavvaru didn't post that comment I was pretty sure it was a regression. I worked around this by adding `position: absolute; top: .01mm;` to the table element. This way the extra padding doesn't show up: https://jsbin.com/vobulel/2/edit?html,css,output
,
Apr 26 2017
edit: `top: .1mm;` is correct.
,
Apr 27 2017
Actually +kavvaru this time. kavvaru, can you clarify your comment 2 as mentioned in comment 3? Also, can you rerun a bisect on recent revisions, as we've had progress and regressions in this area starting around M52. We can use sassanh's estimate of M54, so run them between m52 and m56.
,
Apr 27 2017
+Needs-Bisect as mentioned in comment 7.
,
Apr 28 2017
dgrogan@ Please find the attached screen shots of both M58(Padding+Margin) & M50(Margin without padding). As per the first comment mentioned in What went wrong? Seems like table in first page has padding-top or thead in first page has margin-top. I have considered both the behaviour as Bad only.apologies for the confusion. Please confirm shall we consider the M50 behaviour as good and do the bisect? Thanks,
,
May 8 2017
Rob, do you already know about the extra padding-like space that showed up in this example?
,
May 9 2017
Seems OK in: Google Chrome 60.0.3088.3 (Official Build) dev (64-bit) Revision 49d525d4dafb21903d1cd21025174928a3fdde75-refs/branch-heads/3088@{#4} OS Linux
,
May 9 2017
Fixed in 60.
,
May 10 2017
Thanks |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kavvaru@chromium.org
, Apr 25 2017