Closed
Bug 29360
Opened 25 years ago
Closed 25 years ago
Crash after Unknown Type dialog comes up.
Categories
(SeaMonkey :: UI Design, defect, P1)
SeaMonkey
UI Design
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: jud, Assigned: bugs)
References
()
Details
(Keywords: crash, regression, Whiteboard: [PDT+])
Attachments
(1 file)
2.47 KB,
text/plain
|
Details |
visist the said URL. You'll notice the unknown content type dialog come up, then a crash (stack below). NS_IMETHODIMP nsFieldSetFrame::Reflow(nsIPresContext* aPresContext, nsHTMLReflowMetrics& aDesiredSize, const nsHTMLReflowState& aReflowState, nsReflowStatus& aStatus) ... mLegendFrame->GetFrameState(&state); ... mLegendFrame is null. nsFieldSetFrame::Reflow(nsFieldSetFrame * const 0x0276611c, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 312 + 19 bytes nsBoxFrameInner::FlowChildAt(nsIFrame * 0x0276611c, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsCalculatedBoxInfo & {...}, int 0, int 0, int 1, nsIFrame * & 0x00000000, int & 0, const nsString & {...}) line 2167 nsBoxFrameInner::FlowChildAt(nsIFrame * 0x0276611c, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsCalculatedBoxInfo & {...}, int 0, int 0, int 1, nsIFrame * & 0x00000000, int & 0, const nsString & {...}) line 1981 + 62 bytes nsBoxFrameInner::FlowChildren(nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, nsIFrame * & 0x00000000, nsRect & {...}, nsSize & {...}, int & 1360) line 1395 nsBoxFrame::Reflow(nsBoxFrame * const 0x02766068, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 1122 nsContainerFrame::ReflowChild(nsIFrame * 0x02766068, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 638 + 31 bytes RootFrame::Reflow(RootFrame * const 0x0276602c, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 331 nsContainerFrame::ReflowChild(nsIFrame * 0x0276602c, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 638 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x02765ff0, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 531 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x03453610, nsIPresContext * 0x033928a0, nsHTMLReflowMetrics & {...}, const nsSize & {...}, nsIRenderingContext & {...}) line 145 PresShell::ProcessReflowCommands(PresShell * const 0x03393e60, int 1) line 2031 ReflowEvent::HandleEvent() line 1931 HandlePLEvent(ReflowEvent * 0x03453570) line 1943 PL_HandleEvent(PLEvent * 0x03453570) line 526 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x01049f50) line 487 + 9 bytes _md_EventReceiverProc(HWND__ * 0x00d3015e, unsigned int 49435, unsigned int 0, long 17080144) line 975 + 9 bytes USER32! 77e71820() 01049f50()
Reporter | ||
Comment 2•25 years ago
|
||
I'm seeing this on windows and linux
Comment 3•25 years ago
|
||
Yeah, I just saw this on a build from tonight (Sunday's) linux tip.
Comment 6•25 years ago
|
||
ooh, this happens on linux, mac and winNT. tested using opt comm bits, 2000022808-m15. also crashed when trying to download an *.exe file. regression... Talkback info for linux: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=43&cp=4&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6020584 Call Stack: (Signature = nsFieldSetFrame::Reflow() d4e1e5fd) nsFieldSetFrame::Reflow() nsBoxFrameInner::FlowChildAt() nsBoxFrameInner::FlowChildAt() nsBoxFrameInner::FlowChildren() nsBoxFrame::Reflow() nsContainerFrame::ReflowChild() RootFrame::Reflow() nsContainerFrame::ReflowChild() ViewportFrame::Reflow() nsHTMLReflowCommand::Dispatch() PresShell::ProcessReflowCommands() HandlePLEvent() PL_HandleEvent() PL_ProcessPendingEvents() nsEventQueueImpl::ProcessPendingEvents() event_processor_callback() our_gdk_io_invoke() libglib-1.2.so.0 + 0xe52a (0x4088b52a) libglib-1.2.so.0 + 0xfbe6 (0x4088cbe6) libglib-1.2.so.0 + 0x101a1 (0x4088d1a1) libglib-1.2.so.0 + 0x10341 (0x4088d341) libgtk-1.2.so.0 + 0x8c209 (0x407b4209) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x181eb (0x4021d1eb) Talkback info for mac, not very useful, so i'll try to attach a Macbugs trace soon: http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=43&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6021041
Severity: critical → blocker
Component: Progress Window → XPApps
Keywords: regression
OS: Windows NT → All
Hardware: PC → All
Comment 7•25 years ago
|
||
Bill, who should _really_ get this bug?
Priority: P3 → P1
Target Milestone: M14
A comment from evaughan that I found in another bug which I think is applicable here: <Eric> The problem is this XUL dialog is using a fieldset. Fieldsets are very problematic in XUL. There is a xul fieldset equivalent called "titledbox". This works very well in xul. Its exactly like a box but has an optional title. Here is an example: <titledbox orient="vertical"> <title><text value="the title"/></title> ... you stuff here.. </titledbox> <Eric/> So a temporary fix may be to not use fieldsets, but I hope the long-term plan involves user feedback of a higher caliber than crashing when the xul writer chooses unwisely. To answer Don's question, to get the crash off our radar, perhaps matt or ben should host this bug for now. Sounds like it really wants to go to one of the authors of the xul content sink.
Updated•25 years ago
|
Whiteboard: [PDT+]
Comment 10•25 years ago
|
||
I talked to Eric about this. There are two bugs. First, the unknown content dialog is using a <fieldset> and it shouldn't. Changing that to a <titledbox> solves that problem and avoids the second bug, which is that a <fieldset> without a <legend> crashes, in at least some circumstances. We should change the <html:fieldset> to <titledbox>. I'm reassigning to Ben to accomplish that. That is a trivial change and solves the problem. My only concern was leaving the <html:div> elements inside that <titledbox>. I think maybe those will need to go, also. I've added Eric Vaughan to the cc: list. I'll search for an existing bug relating to <fieldset>s without <legend>s and if there isn't one, I'll open a new bug to track that. That problem might not be PDT+.
Assignee: law → ben
Assignee | ||
Comment 11•25 years ago
|
||
and I now have a reviewed and tested fix. damnit, where's jevering when you need him.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•25 years ago
|
||
fix checked in...
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 13•25 years ago
|
||
verif w/200002290x: linux and winNT: opt comm bits. mac: opt, non-comm bits.
Status: RESOLVED → VERIFIED
Comment 14•25 years ago
|
||
*** Bug 29796 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 15•25 years ago
|
||
*** Bug 29554 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•