Closed Bug 1107508 Opened 5 years ago Closed 5 years ago
Firefox freezes when keyframe animation is about to start
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
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
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.
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.
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!
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.