Issue metadata
Sign in to add a comment
|
fast/text/large-text-composed-char.html needs to be rebaselined when mojo-loading is enabled |
||||||||||||||||||||||||
Issue descriptionfast/text/large-text-composed-char.html dumps a layout tree containing a large text. In blink, a large text can be split to multiple text dom nodes (blink::Text) and its boundary can depend on data chunk segments coming from the browser process. DocumentLoader::commitData appends data to an HTMLDocumentParser via DocumentWriter. The parser parses the data and generates a DOM tree with HTMLConstructionSite, but text data (stored in HTMLConstructionSite::m_pendingText) can be split into multiple text nodes. The divided text nodes can be observable with LayoutTreeAsText.
,
Dec 26 2016
There are several solutions: 1. Fix the layout test 2. Rebaseline the layout test result 3. Fix LayoutTreeAsText 4. Fix HTML parser I would like to choose the second option because I don't understand the layout test and fixing LayoutTreeAsText may complicate it. Merging text data will regress the performance as written in HTMLConstructionSite::flushPendingText.
,
Dec 26 2016
cc-ing html parser and layout experts. If my understanding above is wrong, please correct me. Thank you!
,
Dec 26 2016
,
Dec 26 2016
Option 2 looks like a decent choice - given that the test still passes of course (i.e all "é"s have both of their parts, codepoints, in the same text node.) I wonder if this particular test wouldn't be better suited as unit test though (where buffer boundaries can be made more obvious.)
,
Dec 27 2016
Taking Option 2 for now sgtm
,
Sep 14 2017
Somehow this issue is resolved.
,
Nov 7 2017
,
Nov 7 2017
Apologies, applied the wrong component in bulk. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by yhirano@chromium.org
, Dec 26 2016