Bug 3742 - Eyes don't render properly in acid2 test With Plugins disabled.
Summary: Eyes don't render properly in acid2 test With Plugins disabled.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 412
Hardware: Mac OS X 10.4
: P3 Normal
Assignee: Nobody
URL: http://webstandards.org/act/acid2/tes...
Keywords:
Depends on:
Blocks:
 
Reported: 2005-06-27 18:02 PDT by Marcus Pallinger
Modified: 2007-11-02 23:47 PDT (History)
4 users (show)

See Also:


Attachments
Possible solution (1.65 KB, text/plain)
2005-06-28 06:59 PDT, Niels Leenheer (HTML5test)
no flags Details
Properly use images and fallback content (4.10 KB, patch)
2005-09-21 14:41 PDT, Niels Leenheer (HTML5test)
mjs: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Marcus Pallinger 2005-06-27 18:02:39 PDT
The eyes in the acid2 test don't appear. Instead, a 50% red band appears, and the black bar on the right of 
the eyes is red.
Comment 1 Joost de Valk (AlthA) 2005-06-27 23:24:54 PDT
Tested in fresh ToT, worksforme. The Tiger version of Safari will probably not pass the acid 2 test yet, the 
built from tree version however does. Thx for the bugreport tho.
Comment 2 Marcus Pallinger 2005-06-27 23:45:11 PDT
I had just updated the tree before I filed the bug. I just updated the tree again, and it now works...
Comment 3 Marcus Pallinger 2005-06-27 23:52:53 PDT
Actually, this works properly with plug-ins enabled, but it doesn't work if the plug-ins are disabled.
Comment 4 Joost de Valk (AlthA) 2005-06-28 03:00:36 PDT
I don't have any plugins installed and it works perfectly... Can somebody else confirm this bug?
Comment 5 Chad Ingram 2005-06-28 05:29:49 PDT
I don't have canconfirm, but I just checked using ToT, and result was exactly as described. 
Safari menu -> Preferences... Security tab, uncheck "Enable plug-ins", (I restarted Safari @ this point, 
might not be needed), load the acid2 test. 
Comment 6 Joost de Valk (AlthA) 2005-06-28 05:33:12 PDT
Confirmed. 
Comment 7 Niels Leenheer (HTML5test) 2005-06-28 06:39:01 PDT
I tracked this problem down to an inability of Webcore to display fallback
content for object elements, when plugins are disabled. This is obviously
problematic, because the fallback content is intented for such situations.

html_objectimpl.cpp:

621: bool HTMLObjectElementImpl::rendererIsNeeded(RenderStyle *style)
622: {
623:     if (m_useFallbackContent || isImageType())
624:         return HTMLElementImpl::rendererIsNeeded(style);
625: 
626:     KHTMLPart* part = getDocument()->part();
627:     if (!part || !part->pluginsEnabled()) {
628:         return false;
629:     }

m_useFallbackContent is initially false and isImageType() will return false
for regular plugin content. This means that line 627 is reached which result
in false being returned if plugins are disabled.

If rendererIsNeeded() returns false, createRenderer() will not be called and
the RenderObject for the fallback content will not be created. The solution is
return always true for rendererIsNeeded() and check which type of renderer we
need to create in the createRenderer() function.
Comment 8 Niels Leenheer (HTML5test) 2005-06-28 06:59:46 PDT
Created attachment 2687 [details]
Possible solution

This attachment contains a possible solution to the problem. The function
listed here should be modified in html_objectimpl.cpp. Sorry, I currently
do not have the time to do a proper patch.
Comment 9 Niels Leenheer (HTML5test) 2005-09-21 14:41:55 PDT
Created attachment 3992 [details]
Properly use images and fallback content

If plugins are disabled by the user, the object element should still be able to
display images, because images are not handled by plugins. The same applies to
fallback content, if plugins are disabled and fallback content is provided, the
fallback content should be displayed instead of the plugin.

(Additionally this patch also makes sure fallback content is shown when the
object element does not contain a type or url, for example:
<object>Hello</object>. This example should simply print 'Hello'.)
Comment 10 Darin Adler 2005-09-23 08:53:24 PDT
Comment on attachment 3992 [details]
Properly use images and fallback content

Patch has at least one tab in it. We indent using spaces, not tabs.

Does this do the right thing when display is "none"? I don't think it does
because rendererIsNeeded is supposed to return false in that case. Yet here was
are returning true just so that we can eventually get to the fallback content
code path.

I think part of the fix should be to move the plug-ins enabled check completely
out of rendererIsNeeded and instead do that check inside updateWidget.

I'd like Dave to review this.
Comment 11 Maciej Stachowiak 2005-10-14 00:10:42 PDT
I'm going to r- based on darin's comments, even though this may need additional review. At the very least 
we need a test case for the display: none case.
Comment 12 David Kilzer (:ddkilzer) 2006-12-13 14:14:55 PST
Reassigning bug to webkit-unassigned for more visibility.
Comment 13 mitz 2007-09-20 10:40:50 PDT
Looks like it is fixed in TOT.
Comment 14 David Kilzer (:ddkilzer) 2007-11-02 23:47:23 PDT
This appears to be fixed.  Tested with a local debug build of WebKit r27388 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218) with plug-ins disabled.

Note that reloading the page after viewing the test for the first time still has issues.  See Bug 13693.