WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
37048
transitions/cancel-transition.html crashed on Leopard Debug Bot
https://bugs.webkit.org/show_bug.cgi?id=37048
Summary
transitions/cancel-transition.html crashed on Leopard Debug Bot
Eric Seidel (no email)
Reported
2010-04-02 15:30:12 PDT
transitions/cancel-transition.html crashed on Leopard Debug Bot
http://build.webkit.org/results/Leopard%20Intel%20Debug%20(Tests)/r57025%20(12365)/transitions/cancel-transition-stderr.txt
ASSERTION FAILED: newOutlineBox == renderer()->outlineBoundsForRepaint(repaintContainer, 0) (/Volumes/Big/WebKit-BuildSlave/leopard-intel-debug/build/WebCore/rendering/RenderLayer.cpp:321 void WebCore::RenderLayer::updateLayerPositions(unsigned int, WebCore::IntPoint*))
http://trac.webkit.org/browser/trunk/LayoutTests/transitions/cancel-transition.html
The ASSERT was added by James Robinson:
http://trac.webkit.org/browser/trunk/WebCore/rendering/RenderLayer.cpp?annotate=blame&rev=57000#L321
Attachments
Patch
(1.56 KB, patch)
2010-04-02 16:30 PDT
,
James Robinson
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1
2010-04-02 15:30:50 PDT
It's possible this could be related to
bug 28461
.
Simon Fraser (smfr)
Comment 2
2010-04-02 15:38:09 PDT
Ah, yes, it crashes if accelerated compositing is disabled.
Simon Fraser (smfr)
Comment 3
2010-04-02 15:47:01 PDT
Where "crash" is an assertion. We're computing a repaint rect on some animating transform whose value is time-dependent.
James Robinson
Comment 4
2010-04-02 16:00:26 PDT
If the ASSERT fails it means that the outline box generated using the cached offset differs from the outline box using the slow path (walking up the container hierarchy to generate the offset). If the offset is time-dependent than this makes sense, the cache offset might be correct at time X but incorrect at time X+1ms. Should I take out the ASSERT()? IMHO the cleanest solution is for all time-dependent values in animations to be fixed when painting a single frame.
Simon Fraser (smfr)
Comment 5
2010-04-02 16:14:51 PDT
> Should I take out the ASSERT()?
For now, yes.
> IMHO the cleanest solution is for all time-dependent values in animations to be fixed when painting a single frame.
I think this is the correct solution, yes. Let's keep this bug open to do that (or file a new one).
James Robinson
Comment 6
2010-04-02 16:30:39 PDT
Created
attachment 52463
[details]
Patch
Simon Fraser (smfr)
Comment 7
2010-04-02 16:37:18 PDT
Comment on
attachment 52463
[details]
Patch I'd like to see a //FIXME comment there that references this bug. r=me
James Robinson
Comment 8
2010-04-02 16:52:37 PDT
Committed
r57033
: <
http://trac.webkit.org/changeset/57033
>
James Robinson
Comment 9
2010-04-02 16:54:10 PDT
The ASSERT() is gone but I don't feel that the underlying bug is fixed.
Eric Seidel (no email)
Comment 10
2010-04-06 23:46:59 PDT
Attachment 52463
[details]
was posted by a committer and has review+, assigning to James Robinson for commit.
Eric Seidel (no email)
Comment 11
2010-05-17 00:34:56 PDT
Comment on
attachment 52463
[details]
Patch Obsoleting patch since this was committed.
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