Bug 64284

Summary: Crash in RenderBox::paintBoxDecorations when documentElement has no renderer
Product: WebKit Reporter: Berend-Jan Wever <skylined>
Component: DOMAssignee: Julien Chaffraix <jchaffraix>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, jchaffraix, rniwa, webkit.review.bot
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows Vista   
Bug Depends on: 68859    
Bug Blocks:    
Attachments:
Description Flags
Proposed fix: NULL-check the documentElement's renderer.
none
Same as previously but added the test to the test_expectations.txt as it ASSERT's in Debug.
none
Fixed EFL Skipped file.
none
Patch for landing none

Description Berend-Jan Wever 2011-07-11 08:24:14 PDT
Chromium: https://code.google.com/p/chromium/issues/detail?id=88926


<body onload="go()"></body>
<script>
  function go() {
    document.open();
    var oUElement = document.createElement("U");
    oUElement.hidden=true;
    oUElement.innerHTML="<style>*{-webkit-border-before-style:groove}";
    document.appendChild(oUElement);
    document.close();
  }
</script>

(Adam, this is the bug I emailed you about before)

The repro triggers an ASSERT in Document::setCompatibilityMode:
webkit\source\webcore\dom\document.cpp
void Document::setCompatibilityMode(CompatibilityMode mode)
{
    if (m_compatibilityModeLocked || mode == m_compatibilityMode)
        return;
    ASSERT(!m_styleSheets->length());
    bool wasInQuirksMode = inQuirksMode();
    m_compatibilityMode = mode;
    if (inQuirksMode() != wasInQuirksMode) {
        // All user stylesheets have to reparse using the different mode.
        clearPageUserSheet();
        clearPageGroupUserSheets();
    }
}

The stylesheet specified in the innerHTML has been added, so m_styleSheets->length() == 1.

This ASSERT does not seem to be obviously related to the eventual NULL ptr crash in RenderBox::paintBoxDecorations:
webkit\source\webcore\rendering\renderbox.cpp
void RenderBox::paintBoxDecorations(PaintInfo& paintInfo, const LayoutPoint& paintOffset)
{
<snip>
    // If we have a native theme appearance, paint that before painting our background.
    // The theme will tell us whether or not we should also paint the CSS background.
    bool themePainted = style()->hasAppearance() && !theme()->paint(this, paintInfo, paintRect);
    if (!themePainted) {
        if (isRoot())
            paintRootBoxFillLayers(paintInfo);
        else if (!isBody() || document()->documentElement()->renderer()->hasBackground()) {
<snip>
}
The last line results in an attempt to call "hasBackground" on the m_style property of a RenderObject. This property is NULL, so this leads to a NULL ptr crash.
Comment 1 Julien Chaffraix 2011-09-26 17:40:42 PDT
The
Comment 2 Julien Chaffraix 2011-11-08 16:49:30 PST
Created attachment 114174 [details]
Proposed fix: NULL-check the documentElement's renderer.
Comment 3 Julien Chaffraix 2011-11-09 10:04:24 PST
Created attachment 114306 [details]
Same as previously but added the test to the test_expectations.txt as it ASSERT's in Debug.
Comment 4 Julien Chaffraix 2011-11-09 11:49:01 PST
Created attachment 114332 [details]
Fixed EFL Skipped file.
Comment 5 Ryosuke Niwa 2011-12-08 16:32:55 PST
Comment on attachment 114332 [details]
Fixed EFL Skipped file.

View in context: https://bugs.webkit.org/attachment.cgi?id=114332&action=review

> LayoutTests/fast/dynamic/crash-paint-no-documentElement-renderer.html:8
> +    if (window.layoutTestController)
> +        layoutTestController.dumpAsText(true);

Why do we need a png?
Comment 6 Julien Chaffraix 2011-12-08 16:54:01 PST
Comment on attachment 114332 [details]
Fixed EFL Skipped file.

View in context: https://bugs.webkit.org/attachment.cgi?id=114332&action=review

>> LayoutTests/fast/dynamic/crash-paint-no-documentElement-renderer.html:8
>> +        layoutTestController.dumpAsText(true);
> 
> Why do we need a png?

We need to make sure the painting code is called or we won't reproduce the crash. I don't think of any way to ensure that without dumping the png. However we really don't care about the image nor the render tree dump.
Comment 7 Ryosuke Niwa 2011-12-08 16:55:16 PST
(In reply to comment #6)
> We need to make sure the painting code is called or we won't reproduce the crash. I don't think of any way to ensure that without dumping the png. However we really don't care about the image nor the render tree dump.

I'm pretty certain painting code is exercised regardless of whether png image is generated or not.
Comment 8 Julien Chaffraix 2011-12-08 16:57:44 PST
(In reply to comment #7)
> (In reply to comment #6)
> > We need to make sure the painting code is called or we won't reproduce the crash. I don't think of any way to ensure that without dumping the png. However we really don't care about the image nor the render tree dump.
> 
> I'm pretty certain painting code is exercised regardless of whether png image is generated or not.

I will double check before landing and adapt the output accordingly.
Comment 9 Julien Chaffraix 2011-12-14 08:55:38 PST
Created attachment 119226 [details]
Patch for landing
Comment 10 Julien Chaffraix 2011-12-14 08:58:55 PST
> > I'm pretty certain painting code is exercised regardless of whether png image is generated or not.
> 
> I will double check before landing and adapt the output accordingly.

Ryosuke was right and I updated the test to dumpAsText() (no png).
Comment 11 WebKit Review Bot 2011-12-14 09:13:54 PST
Comment on attachment 119226 [details]
Patch for landing

Clearing flags on attachment: 119226

Committed r102787: <http://trac.webkit.org/changeset/102787>
Comment 12 WebKit Review Bot 2011-12-14 09:13:59 PST
All reviewed patches have been landed.  Closing bug.
Comment 13 Berend-Jan Wever 2011-12-16 05:57:21 PST
*** Bug 51647 has been marked as a duplicate of this bug. ***