Issue metadata
Sign in to add a comment
|
Table layout inconsistent under zoom when borders are present
Reported by
potassiu...@gmail.com,
Sep 25 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Example URL: http://sinst.html.xdomain.jp/zengaku/jkkn/chrome_bug2.html Steps to reproduce the problem: 1. Use a desktop PC 2. Place HTML tags of the table such as <td> and <th> (Wide letters such as Japanese and Korean is desirable) 3. Specify border property in CSS for <th> or <td> (like 'border: 2px solid black') 4. Change the display zoom of the page What is the expected behavior? In the specification of CSS, the width of the element itself and the width of border should be independent, so even if the width of border is changed, the width of the element itself should not be affected. What went wrong? Normally, the width of the table is automatically determined from the width of the contents of <th> or <td>, but if you specify border property in CSS for <th> or <td>, the rendering of table width becomes unstable. Specifically, when changing the display zoom of the page, the rendering width seems to be slightly smaller than the actual character string width depending on the zoom, and the last letter is unnecessarily breaked and wrapped onto the next line. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Chrome 54 Does this work in other browsers? Yes Chrome version: 61.0.3163.100 Channel: stable OS Version: 10.0 Flash Version: This bug is hard to happen in English. (However, in an extremely small zoom such as 33%, I've confirmed the same bug in English text.)
,
Sep 25 2017
And I did confirm it on Linux. Layout changes for both English and Japanese at various zoom scales.
,
Sep 25 2017
,
Sep 25 2017
,
Dec 23 2017
This bug has been handled as duplication of issue 377847, but unfortunately I'm not convinced much... Has this bug really existed for such a long time? At least, it may be true that the cause of this bug is strongly related to issue 377847, but the phenomenon of this " Issue 768322 " itself began to occur only after chrome 55 and later. That's why I've wrote "Did this work before? Yes Chrome 54" above. In other words, it is certain that something new changes have been made since chrome 55. That change must be the root cause of this bug. I hope that the investigation of the cause will progress.
,
Dec 23 2017
TE team, can you run a bisect using the reporter's URL if it's still available or the attachment in c3 otherwise? The reporter notes the problem started in chrome 55. Potassium, note that even if we do find the change that caused this, we might not be able to practically fix it until issue 377847 is fixed.
,
Dec 23 2017
Thank you for noticing my postscript. "even if we do find the change that caused this, we might not be able to practically fix it until issue 377847 is fixed" OK, I acknowledge that point.
,
Dec 26 2017
Able to reproduce the issue on Mac 10.12.6, Win-10 and Ubuntu 14.04 using chrome stable version #63.0.3239.108 but the same is not reproducible in the latest canary #65.0.3303.0 and latest beta #64.0.3282.39. Reverse Bisect Information: ===================== Good build: 64.0.3252.0 Revision(512362) Bad Build : 64.0.3251.0 Revision(512036) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/571e1dc6eb49feda8fcf4b875377af4cf9d28b4a..1e16b03e287a4a593f5899f4de3d605be81f364b From the above change log suspecting below change Change-Id: I0f9ebafe8b8e1ebbdea01716a7dca14961dbb678 Reviewed-on: https://chromium-review.googlesource.com/742141 wangxianzhu@ - Could you please check and merge the fix to M-63 if it is a valid candidate. Note: Adding label RBS as it seems to be a recent regression. Please feel free to remove the same if not appropriate. Thanks...!! |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dtapu...@chromium.org
, Sep 25 2017