Bug 158245 - Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically)
Summary: Bopomofo ruby in Dictionary.app is written horizontally (when it should be wr...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2016-05-31 17:47 PDT by Myles C. Maxfield
Modified: 2016-06-03 19:03 PDT (History)
6 users (show)

See Also:

Attachments
WIP (3.38 KB, patch)
2016-05-31 17:48 PDT, Myles C. Maxfield 		no flags Details | Formatted Diff | Diff
Patch (7.32 KB, patch)
2016-06-01 18:38 PDT, Myles C. Maxfield 		no flags Details | Formatted Diff | Diff
Patch (344.93 KB, patch)
2016-06-01 19:02 PDT, Myles C. Maxfield 		darin: review+
Details | Formatted Diff | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 2016-05-31 17:47:42 PDT 
Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically)
Comment 1 Myles C. Maxfield 2016-05-31 17:48:32 PDT 
Created attachment 280201 [details]
WIP
Comment 2 Myles C. Maxfield 2016-05-31 17:49:34 PDT 
<rdar://problem/25675318>
Comment 3 Myles C. Maxfield 2016-06-01 18:38:54 PDT 
Created attachment 280291 [details]
Patch
Comment 4 Myles C. Maxfield 2016-06-01 19:02:21 PDT 
Created attachment 280293 [details]
Patch
Comment 5 Darin Adler 2016-06-02 11:23:01 PDT 
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 6 Myles C. Maxfield 2016-06-03 19:00:44 PDT 
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.
Comment 7 Myles C. Maxfield 2016-06-03 19:03:37 PDT 
Committed r201677: <http://trac.webkit.org/changeset/201677>