Bug 102975 - Node::createRenderer should never return null
Summary: Node::createRenderer should never return null
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Elliott Sprehn
URL:
Keywords:
Depends on: 102986 103475
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-21 13:18 PST by Elliott Sprehn
Modified: 2013-01-15 11:34 PST (History)
5 users (show)

See Also:


Attachments
Patch (2.56 KB, patch)
2012-11-21 13:22 PST, Elliott Sprehn
no flags Details | Formatted Diff | Diff
Patch (2.58 KB, patch)
2012-11-21 14:01 PST, Elliott Sprehn
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Elliott Sprehn 2012-11-21 13:18:21 PST
Node::createRenderer should never return null
Comment 1 Elliott Sprehn 2012-11-21 13:22:24 PST
Created attachment 175507 [details]
Patch
Comment 2 Ojan Vafai 2012-11-21 13:39:49 PST
Comment on attachment 175507 [details]
Patch

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

> Source/WebCore/dom/NodeRenderingContext.cpp:234
> +    ASSERT(newRenderer);

There are some codepaths that ASSERT_NOT_REACHED and then return null. If this isn't actually a performance improvement, it might be better to be a bit more defensive here. How about:
if (!newRenderer) {
    ASSERT_NOT_REACHED();
    return;
}
Comment 3 Elliott Sprehn 2012-11-21 13:47:30 PST
(In reply to comment #2)
> (From update of attachment 175507 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=175507&action=review
> 
> > Source/WebCore/dom/NodeRenderingContext.cpp:234
> > +    ASSERT(newRenderer);
> 
> There are some codepaths that ASSERT_NOT_REACHED and then return null. If this isn't actually a performance improvement, it might be better to be a bit more defensive here. How about:
> if (!newRenderer) {
>     ASSERT_NOT_REACHED();
>     return;
> }

The return value is required for the code to compile, we could return anything there. If you return true from rendererIsNeeded and then return 0 from createRenderer the program should crash in a release build. I don't think it makes sense to protect against this case.

(Similarly returning null from styleForRenderer() is a fatal error and we assert about it right above this, but we don't protect you from developer error of doing that)
Comment 4 Elliott Sprehn 2012-11-21 13:50:27 PST
(In reply to comment #3)
> ...

Btw, I don't feel very strongly about this, I can add the protection if you want. :)
Comment 5 Elliott Sprehn 2012-11-21 14:01:38 PST
Created attachment 175517 [details]
Patch

Add return after assert
Comment 6 Ojan Vafai 2012-11-21 14:03:34 PST
Comment on attachment 175507 [details]
Patch

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

>>> Source/WebCore/dom/NodeRenderingContext.cpp:234
>>> +    ASSERT(newRenderer);
>> 
>> There are some codepaths that ASSERT_NOT_REACHED and then return null. If this isn't actually a performance improvement, it might be better to be a bit more defensive here. How about:
>> if (!newRenderer) {
>>     ASSERT_NOT_REACHED();
>>     return;
>> }
> 
> The return value is required for the code to compile, we could return anything there. If you return true from rendererIsNeeded and then return 0 from createRenderer the program should crash in a release build. I don't think it makes sense to protect against this case.
> 
> (Similarly returning null from styleForRenderer() is a fatal error and we assert about it right above this, but we don't protect you from developer error of doing that)

Yeah. I'm on the fence.
Comment 7 WebKit Review Bot 2012-11-21 14:36:43 PST
Comment on attachment 175517 [details]
Patch

Clearing flags on attachment: 175517

Committed r135437: <http://trac.webkit.org/changeset/135437>
Comment 8 WebKit Review Bot 2012-11-21 14:36:47 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 WebKit Review Bot 2012-11-21 15:46:37 PST
Re-opened since this is blocked by bug 102986
Comment 10 Elliott Sprehn 2012-11-23 13:02:07 PST
So it turns out there's a bug my CL uncovered:

Node::rendererIsNeeded has:
(document()->documentElement() == this) || (context.style()->display() != NONE);

Element::createRenderer has a special case for this:
// Ignore display: none on root elements.  Force a display of block in that case.
if (document()->documentElement() == this && style->display() == NONE) {
   RenderBlock* result = new (arena) RenderBlock(this);
   ...
}

but then in HTMLElement::createRenderer we don't call super:

return RenderObject::createObject(this, style);

so in an HTML document display: none on the root element is NOT ignored!

This was introduced way back in https://trac.webkit.org/changeset/21405 when adding a special case for <wbr> elements in HTMLElement::createRenderer.
Comment 11 Elliott Sprehn 2013-01-15 11:34:59 PST
(In reply to comment #10)
> ...
> so in an HTML document display: none on the root element is NOT ignored!
> 

I fixed the bug with the documentElement in r136331, but having dug deeper I think it'd be a time consuming task to make createRenderer never return null as in this original bug, and I'm not sure it has a lot of benefits since we'd still need the if statement check in NodeRenderingContext.