Closed Bug 192469 Opened 22 years ago Closed 22 years ago

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

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: roc)

References

Details

(Keywords: crash, regression, Whiteboard: [fix])

Attachments

(1 file, 2 obsolete files)

no
1.21 KB, patch
bzbarsky
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
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.
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
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
Attached patch fix (obsolete) — — Splinter Review 
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-
Attached patch patch (obsolete) — — Splinter Review 
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-
Attached patch no — — Splinter Review 

        Attachment #113974 -
        Attachment is obsolete: true

    
    

    
  
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
Closed: 22 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 195714 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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.

    
  

        Attachment #113975 -
        Flags: approval1.3?

    
    

    
  
Done so.


    
    

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

    
    

    
  
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?

    
    

    
  
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...

    
    

    
  
*** Bug 197573 has been marked as a duplicate of this bug. ***
Component: Layout: View Rendering → Layout: Web Painting

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: