New issue
Advanced search Search tips

Issue 687217 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Feb 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Range.getBoundingClientRect() returning incorrect values with certain characters

Reported by jmor...@cafex.com, Jan 31 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.76 Safari/537.36

Steps to reproduce the problem:
1. Create an element containing the text 'fi' 
2. Select this element (as the start and end node)
3. Create a Range object - document.createRange();
4. Set the range using setStart and setEnd as the 'f' and then 'i'
5. Observe the bounds returned from range.getBoundingClientRect();

What is the expected behavior?
1) bounds.width of 'f' and 'i' should be their own bounds (not the same)
2) bounds.left of the 'i' is expected to be the width of 'f'

What went wrong?
The bounds of 'f' and 'i' are are the same and the width covers both characters. 

Did this work before? Yes Chrome 48

Does this work in other browsers? Yes

Chrome version: 56.0.2924.76  Channel: stable
OS Version: OS X 10.11.5
Flash Version: Shockwave Flash 24.0 r0

Here is a jsfiddle which draws around the bounds to show the difference cross-browser and with other characters:
https://jsfiddle.net/jMorris676/vatxzvda/

There's also another fiddle from another (solved) issue that can demonstrate this:
https://jsfiddle.net/b1kd0fcp/ (Edit 'Hello' or 'World' to have 'fi' and try to select 'fi'

'i' and 'l' after 'f' will reproduce this.

Please let me know if this is expected (and fixed) behaviour and whether there is an alternative solution to what I'm attempting to do.

 
Labels: Needs-Bisect Needs-Triage-M56
Labels: -Pri-2 -Needs-Bisect M-58 hasbisect Pri-1
Status: Untriaged (was: Unconfirmed)
Able to reproduce the issue on Mac 10.12.2 using chrome reported version #56.0.2924.76 and latest canary #58.0.2998.0.

Unable to reproduce this issue on Linux and Windows.

Bisect Information:
=====================
Good build: 49.0.2573.0  Revision(361233)
Bad Build : 49.0.2574.0  Revision(361527)	

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/8844981696a05f72b6814771a74bec4e410ad71e..32305380195864dce4ac3ad965302a338e4c92d0

Unable to find any suspect from the above changelog.

Could anyone from the dev team please have a look into this issue.

Note: Used the URL: https://jsfiddle.net/jMorris676/vatxzvda/ to test this issue.

Thanks...!!

Comment 3 by tkent@chromium.org, Feb 3 2017

Components: -Blink>Editing Blink>Layout
Owner: e...@chromium.org
Status: Assigned (was: Untriaged)
Maybe this one?
> Mark AlwaysUseComplexText as stable by eae

Labels: -Needs-Triage-M56

Comment 5 by e...@chromium.org, Feb 10 2017

Status: WontFix (was: Assigned)
This is due to us enabling ligatures by default, with ligatures the two characters map to the same "fi" glyph. This is by design.

We are considering exposing information about the individual components of a ligature but that is slightly different.

If ligatures are not desired they can be disabled using CSS.

Sign in to add a comment