WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
84558
REGRESSION(109981): Twitter map buddy icon drawn in the wrong place
https://bugs.webkit.org/show_bug.cgi?id=84558
Summary
REGRESSION(109981): Twitter map buddy icon drawn in the wrong place
Tim Horton
Reported
2012-04-22 20:15:06 PDT
See the attached screenshot; the buddy icon should be on top of the map pin, not the wrong size and off to the right. I've confirmed that reverting 109981 locally does fix this. Link to sample tweet:
http://twitter.com/#!/rgov/status/193865347286310912
Attachments
example
(509.19 KB, image/tiff)
2012-04-22 20:15 PDT
,
Tim Horton
no flags
Details
Screenshot
(64.38 KB, image/png)
2012-04-23 15:08 PDT
,
Simon Fraser (smfr)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Tim Horton
Comment 1
2012-04-22 20:15:27 PDT
Created
attachment 138286
[details]
example
Radar WebKit Bug Importer
Comment 2
2012-04-23 10:51:45 PDT
<
rdar://problem/11300978
>
Adrienne Walker
Comment 3
2012-04-23 14:00:05 PDT
That's really strange. Why is Safari turning on accelerated compositing for this page? This works fine in Chromium with and without accelerated compositing turned on.
Simon Fraser (smfr)
Comment 4
2012-04-23 14:02:17 PDT
> Why is Safari turning on accelerated compositing for this page?
Google maps forces compositing via 3d transforms.
Tim Horton
Comment 5
2012-04-23 15:00:33 PDT
Rolled out in
http://trac.webkit.org/changeset/114950
Adrienne Walker
Comment 6
2012-04-23 15:00:53 PDT
(In reply to
comment #4
)
> > Why is Safari turning on accelerated compositing for this page? > > Google maps forces compositing via 3d transforms.
I just see an affine transform attached to the map in Chromium's inspector. In Safari it is true that many elements get translateZ(0), but I don't see any layer borders (even though I do on poster circle). So, it doesn't look like it's actually going through accelerated compositing, unless it's all going into the root graphics layer. However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me. thorton, smfr: Can you provide another repro case or more details about how to repro with that twitter page?
Simon Fraser (smfr)
Comment 7
2012-04-23 15:08:24 PDT
<div class="map_canvas notransform" data-tweet-id="193865347286310912" data-place-id="d0fc0f618c1eb790" data-place-name="Half Moon Bay, CA" style="position: relative; background-color: rgb(229, 227, 223); overflow: hidden; -webkit-transform: translateZ(0px); ">
Simon Fraser (smfr)
Comment 8
2012-04-23 15:08:38 PDT
Created
attachment 138431
[details]
Screenshot
Tim Horton
Comment 9
2012-04-23 15:18:16 PDT
(In reply to
comment #6
)
> However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me.
I can reliably reproduce the problem on Lion with any Safari/WebKit build between your change and my rollout.
Adrienne Walker
Comment 10
2012-04-23 17:29:58 PDT
(In reply to
comment #9
)
> (In reply to
comment #6
) > > However, in both ToT Chrome (Linux Desktop) and ToT Safari (10.6 Desktop) the page looks fine to me. > > I can reliably reproduce the problem on Lion with any Safari/WebKit build between your change and my rollout.
I can see this repro in Safari on Lion, but it seems like this doesn't reproduce on 10.6 because of accelerated canvas differences. Is there a way to force that on for non-Lion builds of Safari? Even if I force accelerated canvas on for Chromium on Linux or 10.6, this bug doesn't repro, even though I get a similar layer structure as smfr's screenshot. From playing with this on Lion, this bug looks like a repaint issue that just happens to be tickled by these changes and not at all related to layer creation correctness. The buddy icon and the skewed icon appear to be drawn into the same layer (judging by the repaint counter on the layer formed by the clip). It briefly appears correctly and then during a second paint operation gets repainted incorrectly. Anything that causes an invalidation cleans it up, so it appears only intermittently. It's really unfortunate to roll that patch out, since the previous code was causing performance problems by creating too many unnecessary layers and the code that patch was removing wasn't correct. Working around this repaint issue that repros for one port on one platform by rolling out an unrelated patch that just happens to tickle a bug doesn't seem like a real solution. Can you create a smaller repro case or a layout test that demonstrates this?
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