Block element inside inline container element with -moz-opacity causes crash

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
--
critical
RESOLVED FIXED
14 years ago
6 years ago

People

(Reporter: Kurt Blackwell, Assigned: roc)

Tracking

({crash, regression})

Trunk
crash, regression
Points:
---
Bug Flags:
blocking1.3 -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fix])

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

14 years ago
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

14 years ago
Confirmed with Mozilla trunk 2002122704 on Windows ME.
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....
Assignee: jst → roc+moz
Status: UNCONFIRMED → NEW
Component: DOM Mozilla Extensions → Layout: View Rendering
Ever confirmed: true
Keywords: crash
OS: Windows 2000 → All
Hardware: PC → All

Comment 3

14 years ago
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)
Keywords: regression
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 on attachment 113971 [details] [diff] [review]
fix

mmm. wrong file?  ;)
Attachment #113971 - Flags: review-
Created attachment 113974 [details] [diff] [review]
patch

It's just not my day.
Attachment #113971 - Attachment is obsolete: true
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?
Attachment #113974 - Flags: review-
Created attachment 113975 [details] [diff] [review]
no
Attachment #113974 - Attachment is obsolete: true
Whiteboard: [fix]
Comment on attachment 113975 [details] [diff] [review]
no

Well, get some!  ;)
Attachment #113975 - Flags: superreview+
Attachment #113975 - Flags: review+
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
*** Bug 195714 has been marked as a duplicate of this bug. ***

Comment 12

14 years ago
Nomating for 1.3 - this is a regression and as roc pointed out in bug 195714 
comment #8 this fix is very safe.
Flags: blocking1.3?
See bug 195714 for more info about why it *_should_* be blocker of 1.3 final.

Comment 14

14 years ago
not gonna hold for this.
Flags: blocking1.3? → blocking1.3-
Nothing to hold, just need to land _ready_ patch.
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.

Updated

14 years ago
Attachment #113975 - Flags: approval1.3?

Comment 17

14 years ago
Done so.

Comment 18

14 years ago
*** Bug 196530 has been marked as a duplicate of this bug. ***

Comment 19

14 years ago
Comment on attachment 113975 [details] [diff] [review]
no

Ummm... this approval request is not necessary - the fix was already in before.
Removing.
Attachment #113975 - Flags: approval1.3?

Comment 20

14 years ago
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

14 years ago
*** Bug 197573 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.