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
•