Created attachment 134714 [details] testcase open the attached test case open the Web Inspector drill down to the base text for a ruby block the highlight is mispositioned (it's mirrored about the center x of the red block). <rdar://problem/11072270> [Sundance10A265]: Characters with furigana cause the wrong character to show as highlighted
There seem to be a couple of issues here. When you have something like <div (flipped)><span><replaced> (1) topLeftLocationOffset() for the replaced element applies flipping (since it looks at containingBlock()), but then RenderInline::mapLocalToContainer() applies the flip again. I think topLeftLocationOffset() should only apply flipping from the container, if it’s a box, not the containingBlock. (2) the way RenderInline::mapLocalToContainer() flips a point, not a rect
Created attachment 139963 [details] Make RenderInline::mapLocalToContainer() apply container flipping only if it hasn’t been applied already
Comment on attachment 139963 [details] Make RenderInline::mapLocalToContainer() apply container flipping only if it hasn’t been applied already Attachment 139963 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12611161 New failing tests: fast/writing-mode/flipped-blocks-inline-map-local-to-container.html
Created attachment 139968 [details] Archive of layout-test-results from ec2-cr-linux-02 The attached test failures were seen while running run-webkit-tests on the chromium-ews. Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #4) > Created an attachment (id=139968) [details] > Archive of layout-test-results from ec2-cr-linux-02 > > The attached test failures were seen while running run-webkit-tests on the chromium-ews. > Bot: ec2-cr-linux-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick The archive doesn’t appear to include the actual results.
Fixed in <http://trac.webkit.org/r115981>.
Odd. It's a ref-test failure. Clearly our layout test archiving did not handle that well.
(In reply to comment #7) > Odd. It's a ref-test failure. Clearly our layout test archiving did not handle that well. Looks like it included the expected.png and expected.html. It should obviously include the actual.png as well. I'm surprised this didn't work. I swear I've seen it copy the actual.png locally before.
(In reply to comment #7) > Odd. It's a ref-test failure. Clearly our layout test archiving did not handle that well. Unfortunately, the output from the ews bot linked in comment #3 doesn't even show that test as failing; it looks like the output is truncated. Would it be possible to save more of the output from the test run in the future? I'm wondering what kind of a failure it was -- maybe if there was a TEXT diff things got weird?
See <http://trac.webkit.org/r115993>. The test called dumpAsText(), which confused the ref test mechanism.
Ah, yeah, if the test was dumpAsText and the reference wasn't, that would be a problem ...