WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
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-
Details
Formatted Diff
Diff
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
Details
View All
Add attachment
proposed patch, testcase, etc.
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
Fixed in <
http://trac.webkit.org/r115981
>.
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.
Top of Page
Format For Printing
XML
Clone This Bug