Bug 158245 – Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically)

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Myles C. Maxfield]

Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically)

[Myles C. Maxfield]

Created attachment 280201 [details]
WIP

[Myles C. Maxfield]

<rdar://problem/25675318>

[Myles C. Maxfield]

Created attachment 280291 [details]
Patch

[Myles C. Maxfield]

Created attachment 280293 [details]
Patch

[Darin Adler]

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.

[Myles C. Maxfield]

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.

[Myles C. Maxfield]

Committed r201677: <http://trac.webkit.org/changeset/201677>