Last Comment Bug 192469 - Block element inside inline container element with -moz-opacity causes crash
: Block element inside inline container element with -moz-opacity causes crash
Status: RESOLVED FIXED
[fix]
: crash, regression
Product: Core
Classification: Components
Component: Layout: View Rendering (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
: Hixie (not reading bugmail)
Mentors:
: 195714 196530 197573 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-09 07:49 PST by Kurt Blackwell
Modified: 2011-08-05 21:25 PDT (History)
11 users (show)
asa: blocking1.3-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
fix (93 bytes, patch)
2003-02-09 15:33 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
bzbarsky: review-
Details | Diff | Splinter Review
patch (1.21 KB, patch)
2003-02-09 15:52 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
bzbarsky: review-
Details | Diff | Splinter Review
no (1.21 KB, patch)
2003-02-09 16:26 PST, Robert O'Callahan (:roc) (email my personal email if necessary)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review

Description Kurt Blackwell 2003-02-09 07:49:59 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030208
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030208

The following example can demonstrate the error:

<HTML>
<BODY>
<SPAN STYLE="-moz-opacity: 0.5">
<P>This is a test</P>
</SPAN>
</BODY>
</HTML>

Once this page is loaded, "This is a test" will not be visible and the browser
will crash when the reload button is pressed.  I have tested replacing SPAN with
other inline containers like TT, SUP, etc and replacing P with other block
elements like DIV and it causes the same fault.

More complex examples (more content, borders, etc) can more easily show
corrupted layout, but still crash in the same way.

I have also testing this with 1.3a with the same result.

Reproducible: Always

Steps to Reproduce:
1.Create HTML file with example shown in details
2.Open HTML file normally
3.Reload page

Actual Results:  
Mozilla crashes as the result of an invalid address.

Expected Results:  
Display the page correctly, and not crash when the page is reloaded.
Comment 1 Cees T. 2003-02-09 12:12:10 PST
Confirmed with Mozilla trunk 2002122704 on Windows ME.
Comment 2 Boris Zbarsky [:bz] (TPAC) 2003-02-09 12:26:39 PST
If there's no JS involved, it's not DOM....

roc, I see the following assertion at pageload a few times:

###!!! ASSERTION: translation failed: 'ok', file
/home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 480

and the crash (in debug; opt build hung) on reload is:

#0  0x40501e30 in main_arena () from /lib/libc.so.6
#1  0x40501df6 in main_arena () from /lib/libc.so.6
#2  0x40e7f4cf in nsBlockFrame::Destroy (this=0x87c1c4c, aPresContext=0x87744e8)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsBlockFrame.cpp:424
#3  0x40ed26d4 in nsLineBox::DeleteLineList (aPresContext=0x87744e8,
aLines=@0x87c1d84)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsLineBox.cpp:310
#4  0x40e7f4c2 in nsBlockFrame::Destroy (this=0x87c1d48, aPresContext=0x87744e8)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsBlockFrame.cpp:422
#5  0x40ed26d4 in nsLineBox::DeleteLineList (aPresContext=0x87744e8,
aLines=@0x87c17cc)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsLineBox.cpp:310
#6  0x40e7f4c2 in nsBlockFrame::Destroy (this=0x87c1790, aPresContext=0x87744e8)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsBlockFrame.cpp:422
#7  0x40ed26d4 in nsLineBox::DeleteLineList (aPresContext=0x87744e8,
aLines=@0x87c0020)
    at /home/bzbarsky/mozilla/xlib/mozilla/layout/html/base/src/nsLineBox.cpp:310
... (normal page teardown sequence)

Nothing too funny-looking about *this in frame 2....
Comment 3 Andrew Schultz 2003-02-09 15:24:41 PST
the crash and layout problems both regressed between linux trunk builds
2002120605 and 2002120722.

backing out bug 90099 fixed the crash, but not the layout issues (the text is
still invisible)
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-02-09 15:33:55 PST
Created attachment 113971 [details] [diff] [review]
fix

The problem is that the broken-out frames aren't being reparented to the
correct view. The reparenting is done only for the special case where the
broken-out frames are positioned. We simply need to do this for every situation
where the broken-out frames get views.

This patch fixes the crash and makes the text appear too :-).
Comment 5 Boris Zbarsky [:bz] (TPAC) 2003-02-09 15:36:49 PST
Comment on attachment 113971 [details] [diff] [review]
fix

mmm. wrong file?  ;)
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-02-09 15:52:56 PST
Created attachment 113974 [details] [diff] [review]
patch

It's just not my day.
Comment 7 Boris Zbarsky [:bz] (TPAC) 2003-02-09 16:05:24 PST
Comment on attachment 113974 [details] [diff] [review]
patch

>     nsHTMLContainerFrame::CreateViewForFrame(aPresContext, inlineFrame,
>                                              aStyleContext, nsnull, PR_FALSE);
> 
>-    if (aIsPositioned) {
>+    nsIView* inlineView;
>+    blockFrame->GetView(aPresContext, &inlineView);

I assume that should be inlineFrame?

roc, have you had enough sleep lately?
Comment 8 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-02-09 16:26:50 PST
Created attachment 113975 [details] [diff] [review]
no
Comment 9 Boris Zbarsky [:bz] (TPAC) 2003-02-09 16:46:25 PST
Comment on attachment 113975 [details] [diff] [review]
no

Well, get some!  ;)
Comment 10 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-02-22 13:38:26 PST
Fix checked in.
Comment 11 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-03-03 06:56:55 PST
*** Bug 195714 has been marked as a duplicate of this bug. ***
Comment 12 Markus Hübner 2003-03-03 07:15:47 PST
Nomating for 1.3 - this is a regression and as roc pointed out in bug 195714 
comment #8 this fix is very safe.
Comment 13 Zibi Braniecki [:gandalf][:zibi] 2003-03-03 07:19:16 PST
See bug 195714 for more info about why it *_should_* be blocker of 1.3 final.
Comment 14 Asa Dotzler [:asa] 2003-03-06 13:47:35 PST
not gonna hold for this.
Comment 15 Zibi Braniecki [:gandalf][:zibi] 2003-03-06 14:13:07 PST
Nothing to hold, just need to land _ready_ patch.
Comment 16 Boris Zbarsky [:bz] (TPAC) 2003-03-06 16:01:36 PST
Yeah, but this was nominated for _blocking_ 1.3 release, not for being checked
in for 1.3.  If you want it to land for 1.3, set the approval request flag on
the patch.
Comment 17 Markus Hübner 2003-03-07 01:06:02 PST
Done so.
Comment 18 Andrew Schultz 2003-03-09 06:47:41 PST
*** Bug 196530 has been marked as a duplicate of this bug. ***
Comment 19 Andreas Kunz 2003-04-20 16:31:36 PDT
Comment on attachment 113975 [details] [diff] [review]
no

Ummm... this approval request is not necessary - the fix was already in before.
Removing.
Comment 20 Andreas Kunz 2003-04-20 16:38:08 PDT
Ohhh... maybe this approval1.3 flag is also used for tracking the rumored 1.3.1?
I think that release is mainly for Mac (xpi), but I'm very sorry if this request
was still active by intention.
However, I'll not reset it because 
a) it is just not possible using the 'Edit' form anymore and 
b) point a) makes me think this flag is not intended for use with 1.3.1
Sorry for the spam...
Comment 21 Jay Patel [:jay] 2003-04-28 14:04:44 PDT
*** Bug 197573 has been marked as a duplicate of this bug. ***

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