Closed Bug 137216 Opened 22 years ago Closed 18 years ago

crash when using position:absolute in xul [@ CreateViewForFrame ]

Categories

(Core :: XUL, defect)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: rossi, Unassigned)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(4 files)

testcase
151 bytes, application/vnd.mozilla.xul+xml
Details
testcase with abs. pos. <html:div/> crashes win32 linux
309 bytes, application/vnd.mozilla.xul+xml
Details
Crashlog from 2d testcase
26.24 KB, text/plain
Details
Testcase for xbl crash
326 bytes, text/xml
Details 
winXP mozilla 2002041203 crashes when loading a page that has an <iframe
style="position:absolute;"/>
Attached file testcase — 
attaching testcase
Okay, we shouldn't crash, but we _don't_ do absolute positioning in XUL (and 
won't).
Can somone post a stacktrace?
testcase works with linux build 20020411 and CVS 2002041221
that testcase does not crash for me in a trunk build from this afternoon (well, 
it has the :hover checkin from dbaron temporarily backed out, but I doubt that 
that would have an effect on this testcase). This is with win2k. rossi: can 
you still get this to crash?
Build 2002041711 crashes in Linux.

I also see a crash on other absolutely positioned elements within an XUL page
e.g. html:DIV or html:IMG.

I have been using XUL templates and RDF to develop an application that generates
a nice 2D layout of elements freely arranged on screen.  I would be very
dissapointed if John Morrison is correct and absolute positioning is not and
will not be supported within XUL documents since this type of user-customisable
2 dimensional layout without absolute positionin is rather more difficult.
Of course I could always use a <stack> to position my elements absolutely :-).
> Of course I could always use a <stack> to position my elements absolutely

Yep :-) (... but we will never to absolute positioning in xul (box) layout,
or at least according to any statement I've ever heard on the issue from hyatt
and (the now departed) evaughan).

Anyways, I cannot get the attachment 79010 [details] to crash with current trunk builds
on win2k or linux. However, I can crash this example which has a abs. pos.
<html:div/>

---
<?xml version="1.0"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
	xmlns:html="http://www.w3.org/1999/xhtml">
  <html:div style="position:absolute;top:100px;left:100px;">
    <html:img src="http://www.mozilla.org/images/mozilla-banner.gif" />
  </html:div>
</window>
---

nsHTMLContainerFrame::CreateViewForFrame(nsIPresContext * 0x01aeb008, nsIFrame
* 0x0287f4b8, nsIStyleContext * 0x00000000, nsIFrame * 0x0287ec54, int
0x00000000) line 546 + 10 bytes
nsCSSFrameConstructor::ConstructFrameByDisplayType(nsCSSFrameConstructor *
const 0x0012f3b4, nsIPresShell * 0x027d3960, nsIPresContext * 0x01aeb008,
nsFrameConstructorState & {...}, const nsStyleDisplay * 0x0287f43c, nsIContent
* 0x028755d8, nsIFrame * 0x0287ec54, nsIStyleContext * 0x0287ef30, nsFrameItems
& {...}) line 6253 + 16 bytes
nsCSSFrameConstructor::ConstructFrameInternal(nsCSSFrameConstructor * const
0x0012f3b4, nsIPresShell * 0x027d3960, nsIPresContext * 0x01aeb008,
nsFrameConstructorState & {...}, nsIContent * 0x028755d8, nsIFrame *
0x0287ec54, nsIAtom * 0x00efbf10, int 0x00000003, nsIStyleContext * 0x0287ef30,
nsFrameItems & {...}, int 0x00000000) line 7305 + 29 bytes
nsCSSFrameConstructor::ConstructFrame(nsCSSFrameConstructor * const 0x0012f3b4,
nsIPresShell * 0x027d3960, nsIPresContext * 0x00000000, nsFrameConstructorState
& {...}, nsIContent * 0x0287ef30, nsIFrame * 0x0287ec54, nsFrameItems & {...})
line 7158
nsCSSFrameConstructor::ProcessChildren(nsCSSFrameConstructor * const
0x0012f3b4, nsIPresShell * 0x027d3960, nsIPresContext * 0x01aeb008,
nsFrameConstructorState & {...}, nsIContent * 0x028754b0, nsIFrame *
0x0287ec54, int 0x00000001, nsFrameItems & {...}, int 0x00000000,
nsTableCreator * 0x028755d8) line 12158 + 38 bytes
nsCSSFrameConstructor::ConstructDocElementFrame(nsCSSFrameConstructor * const
0x0012f3b4, nsIPresShell * 0x027d3960, nsIPresContext * 0x01aeb008,
nsFrameConstructorState & {...}, nsIContent * 0x028754b0, nsIFrame *
0x0287e9c0, nsIStyleContext * 0x00000000, nsIFrame * & 0x0287ec54) line 3448
nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const
0x0282a9c8, nsIPresContext * 0x01aeb008, nsIContent * 0x028754b0, nsIContent *
0x0287ea88, int 0x0287ec54, nsILayoutHistoryState * 0x00000000, int 0x00000000)
line 8721
StyleSetImpl::ContentInserted(StyleSetImpl * const 0x0281d870, nsIPresContext *
0x01aeb008, nsIContent * 0x00000000, nsIContent * 0x028754b0, int 0x00000000)
line 1525
PresShell::InitialReflow(PresShell * const 0x0287e988, int 0x0000300c, int
0x00002454) line 2613
nsXULDocument::StartLayout(nsXULDocument * const 0x0012f3b4) line 4551
nsXULDocument::ResumeWalk(nsXULDocument * const 0x0012f3b4) line 6092
nsXULDocument::EndLoad(nsXULDocument * const 0x02826588) line 1798 + 7 bytes
XULContentSinkImpl::DidBuildModel(XULContentSinkImpl * const 0x02826588, int
0x00000000) line 537
nsExpatDriver::DidBuildModel(nsExpatDriver * const 0x0287ad08, unsigned int
0x00000000, int 0x00000001, nsIParser * 0x02842d40, nsIContentSink *
0x0280e6c0) line 881 + 22 bytes
nsParser::DidBuildModel(nsParser * const 0x0012f3b4, unsigned int 0x00000000)
line 1250 + 13 bytes
nsParser::ResumeParse(nsParser * const 0x0012f3b4, int 0x00000001, int
0x00000001, int 0x00000001) line 1790
nsParser::OnStopRequest(nsParser * const 0x02842d44, nsIRequest * 0x02715e38,
nsISupports * 0x00000000, unsigned int 0x00000000) line 2419
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x02842d44,
nsIRequest * 0x02715e38, nsISupports * 0x00000000, unsigned int 0x00000000)
line 255
nsFileChannel::OnStopRequest(nsFileChannel * const 0x02715e40, nsIRequest *
0x0285092c, nsISupports * 0x00000000, unsigned int 0x00000000) line 480 + 14
bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0012f3b4) line
213
PL_HandleEvent(PLEvent * 0x0287560c) line 597
PL_ProcessPendingEvents(PLEventQueue * 0x100312ef) line 526 + 6 bytes
_md_EventReceiverProc(HWND__ * 0x00ef5078, unsigned int 0x00401ef3, unsigned
int 0x00ecae60, long 0x7803ce38) line 1078
nsAppShellService::Run(nsAppShellService * const 0x00ecae60) line 309
main1(int 0x00000001, char * * 0x00253ba8, nsISupports * 0x00252ba8) line 1414
+ 9 bytes
main(int 0x00000001, char * * 0x00253ba8) line 1762 + 26 bytes
WinMain(HINSTANCE__ * 0x00400000, HINSTANCE__ * 0x00400000, char * 0x0013347c,
HINSTANCE__ * 0x00400000) line 1782 + 23 bytes
MOZILLA! WinMainCRTStartup + 308 bytes
KERNEL32!
*** Bug 224365 has been marked as a duplicate of this bug. ***
Keywords: crash, testcase
OS: Windows XP → All
Summary: crash when using position:absolute in xul iframe → crash when using position:absolute in xul [@ CreateViewForFrame ]
transferring nomination from dupe.
Flags: blocking1.6b?
Flags: blocking1.6b? → blocking1.6b-
So the first problem I am seeing here is:

###!!! ASSERTION: GetParentWithView failed: 'parent', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp,
line 532

on the positioned frame.  This is because its parent is
aState.mAbsoluteItems.containingBlock, which is null in this case (there is no
absolute containing block on the stack.

Should the root XUL frame claim to be the absolute containing block?  Or what?
We have a similar problem when the root element is a table.  See bug 231776,
especially bug 231776 comment 2.
Depends on: 231776
Crash sufficiently bad enough to activate Apple's bug reporting feedback.
Bugzilla didn't pickup my build comments.

Crash occured with Camino nightly 2004030908 running under Mac OS 10.3.2.
still crashes on mozilla.org: linux 1.6b; Debian GNU/Linux: firefox 0.8-9;
Mozilla 2:1.6-5

###!!! ASSERTION: GetParentWithView failed: 'parent', file
nsHTMLContainerFrame.cpp, line 547
Break: at file nsHTMLContainerFrame.cpp, line 547

Program ./mozilla-bin (pid = 12055) received signal 11.
Stack:
_ZN13nsProfileLock18FatalSignalHandlerEi+0x00000052
[/mnt/store/GNU+Linux/mozilla/mozf/mozilla/dist/bin/components/libprofile.so
+0x00030682]
Sleeping for 5 minutes.
Type 'gdb ./mozilla-bin 12055' to attach your debugger to this thread.

We know it crashes.  Bug 231776 needs to be fixed before it will stop crashing.
Blocks: 131008
Blocks: 274791
*** Bug 274791 has been marked as a duplicate of this bug. ***
I believe I've run into this bug as well. The following xul and css code will
crash Firefox:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>
<?xml-stylesheet href="style.css" type="text/css"?>
	
<window title="XUL Labels"
        xmlns:html="http://www.w3.org/1999/xhtml"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">

<vbox flex="1" style="overflow: auto">
<groupbox class="centered">
	<description style="width: 50px;">
		This is a multi-line description. 
		It should wrap if there isn't enough room to put it in one line.
		Let's put in another sentence for good measure.
	</description>
</groupbox>
</vbox>

</window>


.centered {
		position: absolute;
		top: 0;
		right: 0;
		bottom: 0;
		left: 0;
		width: 50%;
		height: 50%;
		margin: auto;
}

(In reply to comment #18)
> I believe I've run into this bug as well. The following xul and css code will
> crash Firefox:
> 
> <?xml version="1.0"?>
> <?xml-stylesheet href="chrome://global/skin" type="text/css"?>
> <?xml-stylesheet href="style.css" type="text/css"?>
> 	
> <window title="XUL Labels"

XUL has not absolute positioning at all, only <stack /> widget.

So why not just made some kind of "return 0;" workaround,
thus making one SEG. FAULT less ?
Assignee: hyatt → nobody
Having seen other depended bugs with just downloaded mozilla and firefox,
I have some results.

*-*-*

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050304 Firefox/1.0+
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050306

bug 137216: OK
bug 231776: OK
bug 131008: OK
<http://ln.hixie.ch/> switch to orenge style: OK


Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050305
131008 CRaSH

*-*-*

My presonal:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050210 Firefox/1.0
(Debian package 1.0+dfsg.1-6)
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050301 Firefox/1.0.1
(Debian package 1.0.1-1)

bug 231776: OK
------  with test case:
<html>
<head>
<style title="Orange">
html { display: table; }
body { display: table-cell; }
h1 { position: absolute; }
</style>
</head>
<body>
<h1>Switch to the "Orange" stylesheet to crash</h1>
</body>
</html>
-------

bug 137216: OK
------ with test case:
<?xml version="1.0"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<iframe style="position:absolute;"/>
</window>
---------

bug 137216: CRaSH
------ with test case:
<?xml version="1.0"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        xmlns:html="http://www.w3.org/1999/xhtml">
<html:div style="position:absolute;top:100px;left:100px;">
  <html:img src="http://www.mozilla.org/images/mozilla-banner.gif" />
</html:div>
</window>
---------

bug 131008: CRaSH
------ with test case:
<?xml-stylesheet href="chrome://global/skin" type="text/css"?>

<window xmlns:html="http://www.w3.org/1999/xhtml"
        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        id="MainWindow"
        title="IWindow Test">
<div style="position:absolute">abc</div>


</window>
---------

<http://ln.hixie.ch/> switch to orenge style: CRaSH
Blocks: 296086
*** Bug 303714 has been marked as a duplicate of this bug. ***
Hi, 

i dont know if this bug is already solved, at least i cant reproduce it with the
testcases atteched. 

But i've encountered the same bug in xbl, and there also just with html elements
like div.
I know now that this isn't supported but firefox realy shouldn't just crash ;)
I have attached a testcase, just make an xul file that uses it and firefox will
crash. 

I have tested the testcase with Firefox 1.5 Beta1, newest Branch and newest trunk.
Attached file Testcase for xbl crash — 

    
    

    
  
Testcases all WFM using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060526 Minefield/3.0a1 ID:2006052604

    
    

    
  
The testcases also all wfm with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060916 Minefield/3.0a1
Most likely fixed by bug 231776.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME

    
  
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets

    
    

    
  
Crashtest added as part of http://hg.mozilla.org/mozilla-central/rev/54417ebbaea2
Flags: in-testsuite+
Crash Signature: [@ CreateViewForFrame ]

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: