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.

I had just updated the tree before I filed the bug. I just updated the tree again, and it now works...

Actually, this works properly with plug-ins enabled, but it doesn't work if the plug-ins are disabled.

I don't have any plugins installed and it works perfectly... Can somebody else confirm this bug?

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.

Confirmed.

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.

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.

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

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.

Reassigning bug to webkit-unassigned for more visibility.

Looks like it is fixed in TOT.

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.