New issue
Advanced search Search tips

Issue 635717 link

Starred by 5 users
Status: Fixed
Owner:
kojii@chromium.org
Closed: Sep 2016
Cc:
kojii@chromium.org
e...@chromium.org
drott@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Compat



Sign in to add a comment

Tab character rendered oddly

Reported by haneef...@gmail.com, Aug 9 2016 
UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Example URL:
https://gist.github.com/haneefmubarak/56f24b716d7712f48d38e095e3c25be4

Steps to reproduce the problem:
1. Create new gist
2. Set indent to "tabs" and spacing to "8"
3. Insert a tab character
4. Write 8 non-tab characters
5. Write another tab character
6. Write a some alphanumeric characters
7. Place a comma
8. Save the gist
9. View weird tab spacing behavior

What is the expected behavior?
The tab character should render as a gap ending at the next tab-stop.

What went wrong?
The tab character is rendered after the word instead of in its place.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes 

Chrome version: 52.0.2743.82  Channel: stable
OS Version: Ubuntu 16.04.1 Xenial Xerus
Flash Version: Shockwave Flash 22.0 r0

System is running KDE (Kubuntu) and using nVidia proprietary drivers.

Other browsers that render correctly (same system):
===============================
Firefox 48.0 release
Opera 40.0.2308.3 beta

I thought that this could be a GitHub issue, but the source sent over the wire by GitHub contains the tab in the correct place.

Oddly enough, a period (.) renders as part of the word.

Comment 1 by ssamanoori@chromium.org, Aug 9 2016

Components: Blink
Labels: Needs-Feedback
Tested the issue on Windows 7, Mac 10.11.6, Ubuntu 14.04 using 52.0.2743.82, latest stable 52.0.2743.116, canary 54.0.2823.0 with below steps:

1.Opened URL: https://gist.github.com/haneefmubarak/56f24b716d7712f48d38e095e3c25be4
2.Observed that ',' for 2,3,5th lines are bit far from end of line in Linux and Mac.
3.Opened dev tools->console.
4.Not seen any errors in console.

Please find attached screenshots of all OS and update if anything missed in triaging the issue.

haneef503@Could you please provide actual and expected behavior screencast for better understanding the issue to triage it further.
635717.jpg
557 KB View Download

Comment 2 by dtapu...@chromium.org, Aug 9 2016

Components: -Blink Blink>Layout
This definitely is different between firefox, edge, and chrome. Seems related to white-space: pre rules.

Comment 3 by e...@chromium.org, Aug 25 2016

Cc: drott@chromium.org kojii@chromium.org e...@chromium.org
Status: Available (was: Unconfirmed)

Comment 4 by thomasanderson@chromium.org, Aug 31 2016

Labels: -OS-Linux OS-All

Comment 5 by kojii@chromium.org, Sep 9 2016

Labels: -Needs-Feedback -OS-All OS-Linux OS-Mac
Confirmed on Mac, Win and Android are ok...that's strange.

Comment 6 by kojii@chromium.org, Sep 9 2016 

 Issue 641928  has been merged into this issue.

Comment 7 by kojii@chromium.org, Sep 10 2016

Labels: -OS-Linux -OS-Mac OS-All
Owner: kojii@chromium.org
Status: Assigned (was: Available)
This is caused by rounding issue, and got repro on Windows too, depends on fonts.

Preferred width and line breaking have slight rounding difference, and thus preferred width jumps to the next tab stop, while line break does not.

Two issues:
1. The min tab width is too small, it should jump to the next stop when it's so close.
2. Preferred width and line breaking having slight rounding difference isn't good.

Making the min tab width larger should fix this issue. It's currently LayoutUnit::epsilon, which is too small for human to identify there's a tab there.

For 2, I'm curious to learn where we round differently in preferred width and line break, but I'm not sure how cleanly we can fit it without side effects at this moment.

Comment 8 by kojii@chromium.org, Sep 12 2016 

Confirmed that positions differ by ~0.015px, which is 1 LayoutUnit, because preferred width is LayoutUnit while line breaker is float. To fix this, we might need to switch line breaker to LayoutUnit, or round to LayoutUnit at LayoutBox boundary.

I'd prefer to fix 1 but leave 2 for future.
Project Member

Comment 9 by bugdroid1@chromium.org, Sep 12 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/371ed3a69920683cccd0431ce9ce7c95ea324845

commit 371ed3a69920683cccd0431ce9ce7c95ea324845
Author: kojii <kojii@chromium.org>
Date: Mon Sep 12 10:13:18 2016

Fix tab is invisible when the next stop is close

This patch fixes tab width to be at least the half of the space width,
so that it is always recognizable.

Before this patch, the minimum was 1/64px, which is too narrow to
recognize a tab is there. It also helps the stability for rounding
errors.

This patch also moves ShapeResult::createForTabulationCharacters() from
HarfBuzzShaper.cpp to ShapeResult.cpp.

BUG= 635717 

Review-Url: https://codereview.chromium.org/2331783002
Cr-Commit-Position: refs/heads/master@{#417905}

[add] https://crrev.com/371ed3a69920683cccd0431ce9ce7c95ea324845/third_party/WebKit/LayoutTests/css3/tab-size-span-expected.html
[add] https://crrev.com/371ed3a69920683cccd0431ce9ce7c95ea324845/third_party/WebKit/LayoutTests/css3/tab-size-span.html
[modify] https://crrev.com/371ed3a69920683cccd0431ce9ce7c95ea324845/third_party/WebKit/Source/platform/fonts/Font.h
[modify] https://crrev.com/371ed3a69920683cccd0431ce9ce7c95ea324845/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzShaper.cpp
[modify] https://crrev.com/371ed3a69920683cccd0431ce9ce7c95ea324845/third_party/WebKit/Source/platform/fonts/shaping/ShapeResult.cpp

Comment 10 by kojii@chromium.org, Sep 13 2016

Status: Fixed (was: Assigned)
Confirmed the fix in Canary for the URL in this bug and also in issue  Issue 641928 .

Comment 11 by kojii@chromium.org, Sep 26 2016 

 Issue 649622  has been merged into this issue.
►

Sign in to add a comment