RESOLVED FIXED 82684
highlight for Ruby text is mispositioned in the Web Inspector
https://bugs.webkit.org/show_bug.cgi?id=82684
Summary highlight for Ruby text is mispositioned in the Web Inspector
Justin Garcia
Reported 2012-03-29 19:42:11 PDT
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
Attachments
testcase (1.57 KB, text/html)
2012-03-29 19:42 PDT, Justin Garcia
no flags
Make RenderInline::mapLocalToContainer() apply container flipping only if it hasn’t been applied already (28.00 KB, patch)
2012-05-02 23:35 PDT, mitz
simon.fraser: review+
webkit.review.bot: commit-queue-
Archive of layout-test-results from ec2-cr-linux-02 (6.24 MB, application/zip)
2012-05-03 00:45 PDT, WebKit Review Bot
no flags
mitz
Comment 1 2012-05-02 10:55:06 PDT
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
mitz
Comment 2 2012-05-02 23:35:09 PDT
Created attachment 139963 [details] Make RenderInline::mapLocalToContainer() apply container flipping only if it hasn’t been applied already
WebKit Review Bot
Comment 3 2012-05-03 00:44:58 PDT
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
WebKit Review Bot
Comment 4 2012-05-03 00:45:04 PDT
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
mitz
Comment 5 2012-05-03 09:27:35 PDT
(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.
mitz
Comment 6 2012-05-03 09:31:53 PDT
Eric Seidel (no email)
Comment 7 2012-05-03 10:13:49 PDT
Odd. It's a ref-test failure. Clearly our layout test archiving did not handle that well.
Ojan Vafai
Comment 8 2012-05-03 12:17:09 PDT
(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.
Dirk Pranke
Comment 9 2012-05-03 16:59:13 PDT
(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?
mitz
Comment 10 2012-05-03 18:09:24 PDT
See <http://trac.webkit.org/r115993>. The test called dumpAsText(), which confused the ref test mechanism.
Dirk Pranke
Comment 11 2012-05-03 18:25:05 PDT
Ah, yeah, if the test was dumpAsText and the reference wasn't, that would be a problem ...
Note You need to log in before you can comment on or make changes to this bug.