| Summary: | Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Myles C. Maxfield <mmaxfield> | ||||||||
| Component: | New Bugs | Assignee: | Myles C. Maxfield <mmaxfield> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | commit-queue, esprehn+autocc, glenn, hyatt, kondapallykalyan, webkit-bug-importer | ||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||
| Version: | WebKit Nightly Build | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Myles C. Maxfield
2016-05-31 17:47:42 PDT
Created attachment 280201 [details]
WIP
Created attachment 280291 [details]
Patch
Created attachment 280293 [details]
Patch
Comment on attachment 280293 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=280293&action=review > LayoutTests/ChangeLog:10 > + Rebaselined fast/table/border-collapsing/004-vertical.html. These results are pixel-identical in > + MiniBrowser and Safari, which means the old render tree dump was wrong. I really don’t understand the logic here. How does the fact that nothing changed visually mean that the old render tree dump was wrong? Are you saying we had a wrong render tree but somehow accidentally got exactly the right results displayed? Can we do something else for the future health of this test? Maybe turn it into a reference test? I guess not because it doesn’t fit into the viewport. Comment on attachment 280293 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=280293&action=review >> LayoutTests/ChangeLog:10 >> + MiniBrowser and Safari, which means the old render tree dump was wrong. > > I really don’t understand the logic here. How does the fact that nothing changed visually mean that the old render tree dump was wrong? Are you saying we had a wrong render tree but somehow accidentally got exactly the right results displayed? Can we do something else for the future health of this test? Maybe turn it into a reference test? I guess not because it doesn’t fit into the viewport. It turns out that this comment is wrong - when I was comparing MiniBrowser and Safari, I resized the windows to get them to line up, which caused full relayouts, which papered over the problem. It turns out that the -expected.txt change is actually due to the creation of the horizontal scrollbar triggering a second layout. Before this patch, this second layout didn't descend deeply into the render tree, however, with this patch, it correctly does. It is a progression. I'll change the comment. Committed r201677: <http://trac.webkit.org/changeset/201677> |