Closed Bug 305564 Opened 19 years ago Closed 19 years ago

CSS parsing errors when <object> with missing plugin does not have width/height attributes

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Version:
1.8 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jruderman, Unassigned)

References

(
URL
)

Details

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050822
Firefox/1.0+

Steps to reproduce:
1. Load data:text/html,<object type="application/wtf"
data="http://www.google.com/images/logo.gif">6</object>

Result:
"Error parsing value for property 'height'." and
"Error parsing value for property 'width'." in the JavaScript console (sometimes
twice).
If you add a width attribute to the <object>, "Error parsing value for property
'width'." goes away, and similarly for height.
Summary: CSS parsing errors associated with "missing plugin" replacement and/or information bar → CSS parsing errors when <object> with misssing plugin does not have width/height attributes
Commenting out the stuff in SizeAnchor in nsObjectFrame.cpp (called by
nsObjectFrame::Reflow) fixes the warnings.  I haven't figured out why, though.
Summary: CSS parsing errors when <object> with misssing plugin does not have width/height attributes → CSS parsing errors when <object> with missing plugin does not have width/height attributes
roc, want this bug?
Assignee: jruderman → nobody
This might have been fixed by the checkin for bug 1156, specifically this hunk:
 
   nsAutoString tmp;
   tmp.AppendInt(aWidth);
-  AppendASCIItoUTF16("px", tmp);
+  tmp.AppendLiteral("px");
+
   css2props->SetWidth(tmp);
 
   tmp.Truncate();
   tmp.AppendInt(aHeight);
-  AppendASCIItoUTF16("px", tmp);
+  tmp.AppendLiteral("px");
+
   css2props->SetHeight(tmp);

I can't test until bug 309521 is fixed.
Group: security
I can't imagine that that change makes any difference.

but that code will go away anyway.

why is this now security-sensitive?
Oops, I must have clicked the "Security-Sensitive Bug" checkbox accidentally.
Group: security
All that happened was that the C++ generated invalid CSS.  Since we're no longer doing that, this should be fixed (by bug 1156), though if you want to wait till bug 309521 is fixed to verify, go for it.
Depends on: 1156, 309521
WFM Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060102 Firefox/1.6a1

Btw, I never see plugin finder activate for <object> on trunk.  It's just replaced by its alternate content, even if it's empty.  Plugin finder does appear for <embed>.
fixed by bug 1156 / bug 309521

pluginfinder requires a pluginurl being present. was that different in 1.0.x?
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
(I tried to match the conditions used for showing the (pre-pluginfinder) nullplugin)
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.