1107508 - Firefox freezes when keyframe animation is about to start

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Alexandre Barreira]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.10 Safari/537.36

Steps to reproduce:

1) Go visit this page https://www.dashlane.com/scan/10/
2) Keyframe animation starts with a delay of 1.5s, so the crash should happen just after page load


Actual results:

Firefox UI froze, had to force quit.


Expected results:

Firefox not freezing.

Comment 1

[Loic]

I got a regression range:

good=2014-01-18
bad=2014-01-19
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=298f262f21ff&tochange=61fd0f987cf2

Comment 2

[Timothy Nikkel (:tnikkel)]

I broke during the hang and I have a stack of several hundred loops of

PresShell::ProcessReflowCommands
PresShell::FlushPendingNotifications
PresShell::FlushPendingNotifications
PresShell::HandlePostedReflowCallbacks
PresShell::DidDoReflow

The reflow callback that causes the us to keep flushing is the scroll frame reflow finished callback.

Not sure what in that regression range would have caused this.

Comment 3

[Matthias Versen [:Matti]]

caused by (via local build)
997c9994cf6b	Robert O'Callahan — Bug 960277. Part 1: Don't optimize away frame reconstruction for 'transform' add/remove if the element has complex abs-pos container structure. r=mats

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The repeating sequence of steps:
1) Pending restyles trigger frame reconstruction via the patch in bug 960277.
2) The frame reconstruction reaches an SVG <use> element.
3) Recreating frames for the <use> element triggers delayed unbinding an anonymous <svg> element containing an SVG <style> element.
4) Unbinding the <style> element requests massive style recomputation. In particular, we go nsPresContext::FlushUserFontSet to rebuild all style data.

I think it's sort of an accident that 960277 triggered this. My guess is it could be reproduced via any form of frame reconstruction.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: testcase

Relatively simple testcase.

Currently Gecko clones the <style> child of #s and applies its rules to the whole document, but only if #b is not display:none. This creates a circular dependency.

I discussed this with heycam and we agreed that disabling stylesheets in <use>-cloned shadow trees is the right thing to do for now. Chrome appears to behave this way. We can alter this later, e.g. by having <use>-cloned stylesheets apply to the shadow tree only.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Comment 7

[Alexandre Barreira]

FYI, this is not reproducible anymore on the provided link since I removed style tags to prevent the issue from happening. Thanks for looking into it!

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/eb15e3f89345

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/eb15e3f89345