end-of-line nowrap white space is not always correctly elided
Reported by
v...@g.nevcal.com,
Jan 23 2017
|
|||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Example URL: http://nevcal.com/temporary/browserbugs/white-space-item-dividers.html Steps to reproduce the problem: 1. Go to URL 2. Adjust window size bigger or smaller 3. Observe that sometimes horizontal lines show up at the end of the <li> lines, but usually not. What is the expected behavior? The horizontal lines are a background image for white-space that should be elided at the end of lines. They should only show up when there are items on both sides, never at the beginning or end of lines. What went wrong? The horizontal line background images show up at some window widths. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: Version 58.0.2990.0 canary (64-bit) Channel: canary OS Version: 10.0 Flash Version: Shockwave Flash 24.0 r0 I was developing this technique in Firefox, where it works rock solid. Did minor testing in Chrome and Opera without noticing. Then tested Edge, and the problem there is solid... every line ends with a horizontal line that shouldn't be there. So then I reworked this page from which I got the original technique, but which worked, to figure out the problem. Once I isolated the problem in Edge, I did more thorough testing in Chrome and Opera and both exhibit the problem at some screen widths. In Edge, I think it is improper handling of nowrap end-of-line spaces. Because it only happens sometimes in Opera and Chrome, I can't be sure it is that, or just a bug in the implementation of nowrap end-of-line spaces, or a layout bug of some sort. The attached file is the same as the file at the URL.
,
Jan 24 2017
,
Jan 24 2017
,
Jan 25 2017
Unable to reproduce the issue on Windows 7, Mac 10.12.2 & Linux Ubuntu 14.04 using latest Canary#58.0.2991.0 & reported version- 58.0.2990.0 as per the steps mentioned in Comment#0 & comment#1. No horizontal lines observed at the end of the lines. if possible could you please provide us the screencast to triage the issue further. Thanks in advance.
,
Jan 25 2017
Today, Canary reports itself as 58.0.2992.0, and the problem still exists. Autohotkey has a tool "Window Spy" that reports on the active window sizes, and other information. For the first screenshot, which shows an end-of-line line after Link 16, which is the end of the third line at that width, the window width was 885, client width 869. I assume the difference is the scroll bar or window frames. It persisted as a shrunk the window width down to 870, client 854, then disappeared. The width of the screen shot taken by IrfanView was 871 (I took the shot at the end of the shrinkage area, I guess, and IrfanView must grab one more pixel than the width reported by Window Spy, or else I jittered the mouse when releasing it for the screen shot.) At width 865, client 849, a line appeared after Link 10, which is the end of the second line at that width. It persists down to width 845, client 829. (2nd screen shot). At width 841, client 825, a line appears after Link 6, which is the end of the first line at that width. It persists down to width 821, client 805, when the whole Link 6 item jumps down to the second line when shrunk slightly further. (3rd screen shot). At width 804, client 788, a line appears after Link multiple item 13, which is the end of the third line at that width. (4th screen shot). It persists down to width 784, client 768. Skipping a few appearances, I continued shrinking the window, and another line appears after Link 14 and then at width 622, client 606, (5th screen shot) there are 2 lines, one after Link 10 (3rd line) and one after Link 14 (4th line). Both persist until width 609, client 593, when Link 14 gets pushed to the 5th line, but Link 10's line stays a few more pixels. At window width 597, client 581, there are two horizontal lines at the end of the first and second lines (Link 4 and Link 8). 6th screen shot. So, as I suggested, you need to change the window sizes, and watch as you do so. Maybe it would be possible to trigger the problem by giving the <ul> a specific width in CSS, but fixing the problem at that specific width might not be a general cure, as the problem doesn't appear at all widths, and a fix might simply change the widths at which it does appear.
,
Jan 25 2017
Regarding the Window Widths, I guess maybe the actual frame size on Windows 10 is only 2 pixels, but Windows reports at as wider for compatibility with older versions. I remember Irfan had to adjust the "window" screen shot when Windows 10 came out because it was picking up pixels around the frame. So for that first screen shot, which I had first commented that I took at window width 885, but the screen shot was narrower, so then I got confused and edit the comment (before submittal) to say it was maybe at the narrower end of that range, it probably is the case that "client width" 869 + 1 pixel of frame on each side of the window, gives the IrfanView screen shot width of 871, even though the report window width from Window Spy is larger.
,
Feb 2 2017
Thank you for providing more feedback. Adding requester "jmukthavaram@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 2 2017
,
Feb 23 2017
v+python@: Could you please check the same on the latest canary(58.0.3021.0) and confirm if the issue is still seen with the provided html file/ fiddle. Thank you!!
,
Feb 23 2017
Thanks for working on this. Looks like maybe it is a hard problem. The first screen shot shows the problem at the end of line 1, the second screen shot shows the failure at the end of line 2 (after link 14 in the buggy grouping).
,
Mar 7 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 7 2018
I guess there is simply no-one that cares about fixing this bug, since it sat here for a year. I suppose adding new whiz-bang features is more fun than mundane bug fixing, even though a reproducible test case has been provided. The problem still recurs on Current Google Chrome Canary 67.0.3364.0 I don't have a clue how to "re-triage" or to trigger "re-triage", and the link for more details doesn't explain that, it only explains what the sheriff does.
,
Mar 7 2018
Fixing some of these issues without causing compatibility problems or breaking other existing web content is really quite hard and time consuming. We're currently in the process of revamping how we do line breaking to fix this (among many other issues) but it is a slow process. Please bare with us.
,
Mar 7 2018
Thanks for the response; I know it is rather a corner case in how things are specified to work, but it is specified that way. I never heard of the sheriff before, and I have no idea how to remove "Hotlist-Recharge-Cold" as the sheriff mentions.
,
Mar 7 2018
Don't worry about that, the sherrif is a bot that periodically comments on issues to make sure we haven't forgotten about them. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by v...@g.nevcal.com
, Jan 23 2017