Issue metadata
Sign in to add a comment
|
Incorrect line breaking for RTL inline-block
Reported by
orit.ha...@sap.com,
Mar 17 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36 Steps to reproduce the problem: 1.open the following jsbin example in Chrome >=49 (the issue can also be observed in the current 50 beta and 51 dev versions) http://jsbin.com/yequjudibu/edit?html,output 2. Check the size of one combination of "SAP SE" and compare it to the size of the second combination "SPA SE". What is the expected behavior? Length of "PA" is identical to "AP" What went wrong? Length of "PA" is different than "AP" (inconsistent calculation) Did this work before? Yes It worked fine in Chrome 48. Chrome version: 49.0.2623.87 Channel: stable OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: Shockwave Flash 21.0 r0 Deeper analysis have shown the following correlations: •This issue is somehow correlated with the string combination AP! There might be some more combinations... It is not only happening, when the string combination is standalone. •The problem of unwanted text wrapping can only be observed with direction:rtl AND display:inline-block •The result is the following (with resolution of 1920 x 1200 – values may be different with other resolutions): - Value for width with direction:ltr > 52,0313px - Value for width with direction:rtl > 50,5625px The smaller width in RTL rendering mode leads to this unwanted text wrapping, which may result in improper UI presentations. Works fine in IE11.
,
Mar 18 2016
,
Mar 18 2016
==================================== Good Build: 49.0.2573.0 Base Position: 361233 Bad Build: 49.0.2575.0 Base Position: 361776 ===================================== Able to repro this issue on Windows 7, MAC (10.11.3) & Ubuntu Trusty (14.04) for the Google Chrome Stable Version - 49.0.2623.87 This is a regression issue broken in M49, below mentioned is the bisect info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/20f3b2d0ee459ed4d743ce9cd8c95417d74f6d04..fa7fc32c5940dfd3d734ed3231b1295da4c3303e Suspecting Commit: fa7fc32c5940dfd3d734ed3231b1295da4c3303e Review URL: https://codereview.chromium.org/1474673003 @eae: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner. Thank you.
,
Mar 23 2016
Any updates on this? This is a regression that has slipped into stable and is affecting all SAP customers i.e. a good chunk of enterprise folks.
,
Mar 23 2016
,
Mar 23 2016
I agree that (from the Changelong) this seems mostly likely to have been triggered by eae's AlwaysUseComplexText feature. eae@ please take a look. Proactively marking RBS as a regression.
,
Mar 23 2016
Looks like we rely on inferred directionality for the preferred width calculation step which results in a width that is slightly less than the actual size. It's already hit Stable so RBS won't help.
,
Mar 24 2016
,
Mar 24 2016
,
Mar 24 2016
Fix landed in https://codereview.chromium.org/1834703002 Will request merge once verified on trunk.
,
Mar 25 2016
,
Mar 26 2016
[Automated comment] Request affecting a post-stable build (M49), manual review required.
,
Mar 26 2016
Your change meets the bar and is auto-approved for M50 (branch: 2661)
,
Mar 28 2016
Please merge your change to M50 branch 2661 ASAP as we're getting closer to this week M50 beta candidate cut.Thank you.
,
Mar 28 2016
,
Mar 29 2016
Merge approved for M49 (branch 2623).
,
Apr 1 2016
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by ashej...@chromium.org
, Mar 17 2016