New issue
Advanced search Search tips

Issue 763661 link

Starred by 3 users
Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
kkaluri@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Text.splitText() triggers relayout, changes positions of text blocks

Reported by igor.v.d...@gmail.com, Sep 9 2017 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce the problem:
1. Open the attached file in Chrome. Zoom level should be set to 100% (default).
2. Click on 'Split!' button to trigger Text.splitText().
3. Notice how "quas. Est" words change their position in line, as well as letter 'i'.
4. Click on 'Restore' button to trigger Node.normalize().
5. Notice how the blocks change their layout back.

What is the expected behavior?
No changes in layout at all.

What went wrong?
Two things are not clear here. First, whether or not Text.splitText() and Node.normalize() should trigger relayout (as well as repaint) at all. Second, whether or not it's normal for such relayout to change positions of text blocks.

Did this work before? N/A 

Does this work in other browsers? No
 The same issue (and seemingly even worse) is observed in Firefox 55 on Windows 10. No such issue is observed in MS Edge 14 on Windows 10.

Chrome version: 60.0.3112.113  Channel: stable
OS Version: 10.0
Flash Version: 

Here's the related thread on SO - https://stackoverflow.com/questions/45818759/why-does-text-splittext-affect-layout
splittext.html
1.9 KB View Download

Comment 1 by woxxom@gmail.com, Sep 9 2017 

Introduced in M35 - r259434 "Support DirectWrite with sandbox on"
* Repro requires command line switch --enable-direct-write
* and a ES5 version of the test html (attached).

Observed by default since M37 - r275860 "Enable DirectWrite by default"
splittext-ES5.html
1.9 KB View Download

Comment 2 by kkaluri@chromium.org, Sep 11 2017

Cc: kkaluri@chromium.org
Labels: Needs-Milestone M-63 OS-Linux OS-Mac
Status: Untriaged (was: Unconfirmed)
Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 with chrome Stable #61.0.3163.79, Canary #63.0.3212.0 and also in earlier M50-#50.0.2661.0. This is a non-regression issue hence marking it as untriaged.

Attaching the screen-cast for reference.
763661.mp4
534 KB View Download

Comment 3 by e...@chromium.org, Sep 11 2017

Status: WontFix (was: Untriaged)
This is working as intended as the start of each text block is aligned with the device pixel grid.

Comment 4 by igor.v.d...@gmail.com, Sep 11 2017 

Is this alignment technique dictated by specification?

And what about letter 'i', how can it change position while no other letters in the same word do?

Comment 5 by woxxom@gmail.com, Sep 11 2017 

The wontfixer won't receive any notifications as their email is not in cc/owner list so it's useless to ask for clarifications here. Might be worth posting another issue here and/or maybe on bugzilla so that hopefully some other developer would link to a spec or explain the rationale.
►

Sign in to add a comment