haikuwebkit/LayoutTests/fast/text/orthogonal-writing-mode-con...

36 lines
951 B
HTML
Raw Permalink Normal View History

Bopomofo ruby in Dictionary.app is written horizontally (when it should be written vertically) https://bugs.webkit.org/show_bug.cgi?id=158245 <rdar://problem/25675318> Reviewed by Darin Adler. Source/WebCore: With orthogonal flows, the inner element gets a logical width that is computed from two values: - The containing block's available logical height - The FrameView's visibleHeight In Dictionary.app, the FrameView's height changes, but this element doesn't get relaid out. This is because of our optimization where normal-flow elements don't get relaid out if their parent's width doesn't change (which is the case here). Therefore, this orthogonal writing mode element should be relaid out when the FrameView changes size. Luckily, we already have machinery for doing this: percentage heights. In quirks mode, a div with a percentage height may walk arbitrarily far up the DOM tree in order to determine which element the percentage should be resolved against. Therefore, we have a map of percentage-sizing- ancestors to percentage-sizing-descendants which speeds up this search. If a percentage-sizing- ancestor gets relaid out, all the relevant percentage-sizing-descendants get relaid out too. Therefore, we can simply mark the FrameView as a percentage-sizing-ancestor and the orthogonal flow element as a percentage-sizing-descendant. The lifetime of this relationship is already managed correctly - it gets reset when style changes and when the renderer is destroyed, and is created during layout. Unfortunately, this same treatment should also be done to the element which dictates the containing block's logical height (which caused https://bugs.webkit.org/show_bug.cgi?id=158286). Implementing this would require giving RenderBox::availableLogicalHeight() a second result of the necessary element which dictates the return. In an effort to keep this patch small and focused, I'll do this secondary (much larger) work in a patch on that bug. This patch, therefore, is kept small and focused. Test: fast/text/orthogonal-writing-mode-containing-block-frameView-resize-relayout.html * rendering/RenderBox.cpp: (WebCore::RenderBox::perpendicularContainingBlockLogicalHeight): LayoutTests: Rebaselined fast/table/border-collapsing/004-vertical.html to show a progression. * fast/text/orthogonal-writing-mode-containing-block-frameView-resize-relayout-expected.html: Added. * fast/text/orthogonal-writing-mode-containing-block-frameView-resize-relayout.html: Added. * platform/mac/fast/table/border-collapsing/004-vertical-expected.png: Rebased * platform/mac/fast/table/border-collapsing/004-vertical-expected.txt: Rebased Canonical link: https://commits.webkit.org/176463@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@201677 268f45cc-cd09-0410-ab3c-d52691b4dbfc
2016-06-04 02:04:58 +00:00
<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
</head>
<body>
This test makes sure that resizing the FrameView causes content with an orthogonal containing block to relayout. The test passes if the Chinese characters below are written vertically.
<div>
<iframe id="iframe" style="width: 700px; height: 0px; border: 0px;" srcdoc="<!DOCTYPE html>
<html>
<head>
<meta charset='utf-8'>
</head>
<body>
<div id='probe' style='-webkit-writing-mode: vertical-rl'>
中华人民共和国
</div>
<div style='width: 1px; height: 2000px; position: absolute; left: 0px; top: 0px;'></div>
</body>
</html>"></iframe>
</div>
<script>
if (window.testRunner)
testRunner.waitUntilDone();
var iframe = document.getElementById("iframe");
iframe.addEventListener("load", function() {
window.setTimeout(function() {
document.getElementById("iframe").style.height = "500px";
if (window.testRunner)
testRunner.notifyDone();
}, 0);
});
</script>
</body>
</html>