New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 740937 link

Starred by 2 users
Status: Duplicate
Merged: issue 6122
Owner:
drott@chromium.org
Closed: Jul 2017
Cc:
█ manoranj...@chromium.org
█ brajkumar@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Width of the DIV-container depends on the number of nested SPAN elements.

Reported by otstavno...@gmail.com, Jul 11 2017 
UserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. Open attached HTML-file
2. Check out the DIV-container's width using method getBoundingClientRect.

What is the expected behavior?
It is expected that the total width of the parent DIV-container should not change while changing the number of child SPAN elements.

What went wrong?
In the attached HTML-file you can find an example in which the same text is displayed with different number of SPAN elements. The greater amount of SPAN-elements is, the greater width of the parent DIV-container is (respectively - 138.55px, 138.56px, 138.59px, 138.63px, 138.64px).

Did this work before? N/A 

Chrome version: 59.0.3071.115  Channel: stable
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
Flash Version:
_!_.html
1.1 KB View Download

Comment 1 by brajkumar@chromium.org, Jul 12 2017

Cc: brajkumar@chromium.org
Labels: Needs-Feedback
Tested this issue on Windows-10 using chrome latest stable #59.0.3071.115. By opening the html file provided in the above comment observed list of sample text in row.

Reporter@ Attaching screen shot for reference, could you please take a look in to it and let me know the issue is seen or not? If yes, please provide the actual and expected behavior screen shot for better understanding. By comparing with the other browser unable to find any difference.

Thanks!
740937.PNG
18.5 KB View Download

Comment 2 by otstavno...@gmail.com, Jul 14 2017 

Visually the texts look really the same way. The problem is not in the displaying, but in the result, which the getBoundingClientRect method returns.
In the attachment you can find an updated HTML-file showing the problem. In the Chrome browser, the result that the getBoundingClientRect method returns is different. In Firefox 54.0.1 and Internet Explorer 11.0.42, the results are the same.
_!_.html
1.7 KB View Download
Project Member

Comment 3 by sheriffbot@chromium.org, Jul 14 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by krajshree@chromium.org, Jul 19 2017

Components: Blink>Fonts
Labels: -Type-Bug -Pri-2 M-60 ReleaseBlock-Stable OS-Mac Pri-1 Type-Bug-Regression
Owner: drott@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10 and mac 10.12.5 using chrome reported version #59.0.3071.115 and latest canary #61.0.3160.0.
Issue is not seen in OS-Linux.

Bisect Information:
=====================
Good build: 59.0.3053.0    Revision(459685)
Bad Build : 59.0.3054.0    Revision(459950)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/dd547f46cfb46ea92f554aa842d06bde19ceef6e..5fd631a31c688954834fc1e297a67b4b1a4f08bc

From the above change log suspecting below change
Change-Id: I02e72ccc4e80e266323445190bc55cebe3ae8dd4
Reviewed-on: https://chromium-review.googlesource.com/458377

drott@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note: Adding label ReleaseBlock-Stable as it seems to have regressed in M-59. Please feel free to remove the same if not appropriate.

Thanks...!!

Comment 5 by krajshree@chromium.org, Jul 19 2017

Cc: manoranj...@chromium.org

Comment 6 by drott@chromium.org, Jul 19 2017

Labels: -Pri-1 -ReleaseBlock-Stable Pri-3
Mergedinto: 6122
Status: Duplicate (was: Assigned)
Before my CL we did not activate subpixel for Arial 10, that's why there was possibly no difference. What you're seeing now, with subpixel enabled, is slight differences due to the fact that we shape differently, when runs are broken by tags/separate inline elements.
►

Sign in to add a comment