Text autosizing cluster multipliers are not consistent if the page loads slowly
Reported by
cathiech...@gmail.com,
May 16 2016
|
||||||
Issue descriptionExample URL: http://x5.imtt.qq.com/2766651/textautosizer/bug.html Steps to reproduce the problem: open http://x5.imtt.qq.com/2766651/textautosizer/bug.html, and we can see the font size of contents is inconsistent.And there is a screenshot attached. What is the expected behavior? What went wrong? <html> <head>...</head> <body> <!-- first parsed chunk--> <somenode>...</somenode> <div>have the exact fingerprint, but not enough text<div> <somenode>...</somenode> <somenode>...</somenode> <div>have the exact fingerprint, but not enough text<div> <somenode>...</somenode> many many nodes in here... <!-- first parsed chunk end--> <!-- second parsed chunk begin--> <somenode>...</somenode> <div>have the exact fingerprint, but not enough text<div> <somenode>...</somenode> <somenode>...</somenode> <div>have the exact fingerprint, have enough text, long long long long long long long long long long long long long long long enough text<div> <somenode>...</somenode> ... <!-- second parsed chunk end--> ... </body> </html> From my perspective: In a long web page, clusters which have the same fingerPrint don't always in the same parsedChunk. For example: http://x5.imtt.qq.com/2766651/textautosizer/bug.html. the 'HasEnoughText' cluster isn't in the first parsedChunk (assuming it is in the second one). In the layout of the first parsedChunk, the clusters with the exact fingerPrint are 'NotEnoughText', so the multiplier is 1.0. And nodes in these clusters are successfully layout, and clearNeedsLayout. Then here comes the second chunk, there is a 'HasEnoughText' cluster, so the multiplier applied is 2.0(or something bigger than 1.0). As the nodes in first chunk are clearNeedsLayout, they can never apply the correct multiplier. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? No Does this work in other browsers? N/A Chrome version: 48.0.2564.95 Channel: n/a OS Version: android 4.4.2 Flash Version: Shockwave Flash 21.0 r0
,
May 18 2016
,
Jul 8 2016
Thanks cathiechen727@gmail.com, excellent analysis. We could go back and synthesize the superclusters, or just keep them around between layouts. I'm going to mark this as available for now.
,
Jul 12 2016
,
Jul 12 2016
,
Aug 16 2016
http://x5.imtt.qq.com is unavailable now. I've put the demo in this URL http://res.imtt.qq.com/qqbrowser_x5/cathiechen/TextAutosize/inconsistent.html
,
Sep 12 2016
Issue 358510 has been merged into this issue.
,
Dec 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf9901feb0c46cefbd5e7af40fe252a6a92d52cb commit bf9901feb0c46cefbd5e7af40fe252a6a92d52cb Author: cathiechen <cathiechen@tencent.com> Date: Fri Dec 16 12:35:44 2016 Fix the inconsistent problem while the content of textNodes is changed. If the text content of one node who share fingerPrint with others changed, the multipiler of this node might be different from others. This's the reason of this inconsistent problem. The solution: 1. Make superclusters across layouts 2. Mark superclusters if needed 2.1 new roots are added to superclusters 2.2 old roots add some new contents 3. Recalculate the multiplier of the marked superclusters during the first beginLayout(). BUG= 612119 Review-Url: https://codereview.chromium.org/2299213003 Cr-Commit-Position: refs/heads/master@{#439093} [modify] https://crrev.com/bf9901feb0c46cefbd5e7af40fe252a6a92d52cb/third_party/WebKit/Source/core/layout/LayoutText.cpp [modify] https://crrev.com/bf9901feb0c46cefbd5e7af40fe252a6a92d52cb/third_party/WebKit/Source/core/layout/TextAutosizer.cpp [modify] https://crrev.com/bf9901feb0c46cefbd5e7af40fe252a6a92d52cb/third_party/WebKit/Source/core/layout/TextAutosizer.h [modify] https://crrev.com/bf9901feb0c46cefbd5e7af40fe252a6a92d52cb/third_party/WebKit/Source/core/layout/TextAutosizerTest.cpp
,
Apr 13 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 23 2018
Closing as per comment 9. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ppolise...@chromium.org
, May 16 2016Owner: pdr@chromium.org
Status: Assigned (was: Unconfirmed)