Closed
Bug 519341
Opened 15 years ago
Closed 6 years ago
Crash in [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)] when closing Firefox, morphing the * selector rule to position:absolute
Categories
(Core :: Layout: Block and Inline, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: Tobbi, Unassigned)
Details
(Keywords: crash, Whiteboard: firebug)
Crash Data
Another bug I could trigger on Firebug with a random XUL file:
1. Load a random XUL file.
2. Open Firebug.
3. Select the * selector.
4. Add position: absolute to the * selector
5. Close Firefox.
Result: Crash in [ @nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
Crash report: http://crash-stats.mozilla.com/report/index/3650880b-cb69-42ef-94ac-7f0dd2090928?p=1
Reporter | ||
Updated•15 years ago
|
Summary: Crash in [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)] morphing the * selector rule to position:absolute on closing the window → Crash in [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)] when closing Firefox, morphing the * selector rule to position:absolute
Comment 1•15 years ago
|
||
This one looks like it might be a null deref from the crash-stats report, but I haven't run it in a debugger to verify that yet.
robcee: will the Firebug fix mentioned in bug 507775 comment 18 prevent this crash as well? Even if so it seems like there's a layout problem to fix.
Whiteboard: firebug
Comment 2•15 years ago
|
||
I would think it would, yes. We'd be preventing modification to any properties in userAgent.css with that fix.
Comment 3•15 years ago
|
||
this is possibly a dupe of 507775. The rule is different, but I think the net result is the same. The user modifies the rule to cause a reflow. crash ensues.
Reporter | ||
Comment 4•15 years ago
|
||
(In reply to comment #3)
> this is possibly a dupe of 507775. The rule is different, but I think the net
> result is the same. The user modifies the rule to cause a reflow. crash ensues.
Sorry to contradict, but:
From the Firebug side, it might be the same, however, the stacks are different, which means that those are actually 2 different crashes that IMO need to be fixed.
(with different patches)
How they're triggered does not really matter, as the fix __does__ prevent the crashes from happening in Firebug, but not from happening in general.
Comment 5•15 years ago
|
||
I don't mind contradiction if I'm saying something wrong. Different stacks mean different bugs.
Dan, do we have any plans for these bugs?
Updated•15 years ago
|
Group: core-security
Reporter | ||
Comment 6•15 years ago
|
||
I'm getting the same crash when I morph the float CSS style rule in firebug to "left" for everything in the XUL namespace.
http://crash-stats.mozilla.com/report/index/bp-e0ff52a4-ed31-40e8-b15f-5347c2100523
Worth a new bug?
Is there any progress going on, currently?
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
Updated•9 years ago
|
Crash Signature: [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)] → [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
[@ nsFrame::BoxReflow]
Comment 7•6 years ago
|
||
(In reply to Tobias (:Tobbi) Markus from comment #0)
> 1. Load a random XUL file.
That's not supported by default anymore.
I don't think the STR is something we'd like to support anyway,
even if you can enable it using hidden prefs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•