Closed Bug 1107508 Opened 5 years ago Closed 5 years ago

Firefox freezes when keyframe animation is about to start

Categories

(Core :: Layout, defect, critical)

29 Branch
x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: abarreir, Assigned: roc)

References

Details

(Keywords: hang, regression)

Attachments

(2 files)

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.
I got a regression range:

good=2014-01-18
bad=2014-01-19
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=298f262f21ff&tochange=61fd0f987cf2
Keywords: regression
Version: 35 Branch → 29 Branch
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
Blocks: 960277
Severity: normal → critical
Flags: needinfo?(roc)
Keywords: hang
Summary: Firefox crashes when keyframe animation is about to start → Firefox freezes when keyframe animation is about to start
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.
Flags: needinfo?(roc)
Attached file 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.
Attached patch fixSplinter Review
Assignee: nobody → roc
Attachment #8535393 - Flags: review?(cam)
Attachment #8535393 - Flags: review?(cam) → review+
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!
https://hg.mozilla.org/mozilla-central/rev/eb15e3f89345
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
QA Whiteboard: [good first verify][testcase in comment #5]
You need to log in before you can comment on or make changes to this bug.