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)

x86
Windows Vista
defect
Not set
critical

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
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
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
I would think it would, yes. We'd be preventing modification to any properties in userAgent.css with that fix.
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.
(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.
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?
Group: core-security
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?
Crash Signature: [@ nsFrame::BoxReflow(nsBoxLayoutState&, nsPresContext*, nsHTMLReflowMetrics&, nsIRenderingContext*, int, int, int, int, int)]
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]
(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.