70972 - Object tag includes do not respect CSS width and height for non-plugins

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Chris Hubick]

If you embed an object in an HTML page using the Object tag, and then set it's
width or height using CSS - the embedded object does not size to those values.

This applies to relative and absolute width and height values.

If you include the image normally using the IMG tag, or set the width as an HTML
attribute on the Object tag, it does work.

This functionality becomes very important when embedding SVG graphics.

Comment 1

[Chris Hubick]

Attachment: Test case

Comment 2

[Keyser Sose]

Confirmed
Platform: PC
OS: Linux 2.2.17
Mozilla Build: 2001030108

Marking NEW.

Comment 3

[karnaze (gone)]

Reassigning to av.

Comment 4

[Boris Zbarsky [:bzbarsky]]

This is also a problem with the <applet> tag

Comment 5

[Peter Lubczynski]

Marc,

Is this just like that other bug I sent you? Should you be the owner?

Comment 6

[Marc Attinasi]

This is probably an issue with how the OBJECT frame is getting the width and
height values (should be taking them from the style context, not the
attributes). I am not sure if this is realted to the other issues I am looking
at, I don't think it is.

Comment 7

[Peter Lubczynski]

Marc,

Where do you think there would be a good example of code of how this should 
work? We should honor CSS properly.

Comment 8

[Marc Attinasi]

Check out SpacerFrame::Reflow and look for where the position->mHeight is used.
That is how you get the value from the style data. You can also make the object
map the attribute values for width and height into the style struct so you only
have one code patch (eg. always use the styl struct and never the attribute
values in Reflow). See MapAttributesInto in nsHTMLSpaceElement.cpp for how that
is done.

Comment 9

[Peter Lubczynski]

-->Alex

Comment 10

[Alexandru Savulov]

neither NAV nor IE displays this issue correctly...

Comment 11

[Chris Hubick]

I sincerely hope NAV and IE aren't the benchmark for CSS compliance in 
Mozilla.  This is a basic CSS1 issue, and should be fixed.

Comment 12

[Alexandru Savulov]

moving to 0.9.3
(nsObjectFrame::HandleImage does not get the width from the style system,
if you use width="50" in the object tag it works because the method calls in 
that case hc->GetHTMLAttribute(nsHTMLAtoms::width, val)...)

chris, i totaly agree with you concerning the compliance with CSS, but i assume 
that the web-designers won't use this feature if it doesn't work with the other 
browsers so we can focus on more urgent bugs

Comment 13

[Alexandru Savulov]

pushing to 0.9.4

Comment 14

[Alexandru Savulov]

pushing to 0.9.5

Comment 15

[Luke Deller]

I've encountered the same problem with <a> and <span> tags; the css width
attribute is not honoured.  I suppose that this is the same bug.  I will attach
a test case.  It works fine with IE5.5 but not with Mozilla 0.9.3.  

Comment 16

[Luke Deller]

Attachment: test case for bug with css "width" with <a> & <span> tags

Comment 17

[Boris Zbarsky [:bzbarsky]]

<a> and <span> are inline tags.  From the spec for 'width' 
(http://www.w3.org/TR/REC-CSS2/visudet.html#the-width-property):

  This property does not apply to non-replaced inline-level elements.

So the fact that IE applies width to <a> and <span> is a bug in IE.

Comment 18

[Peter Lubczynski]

My recent patch to bug 27478 may have fixed this. Can someone test with a recent
build?

Comment 19

[Boris Zbarsky [:bzbarsky]]

still seeing this with a build pulled at "Mon Sep 24 10:51:47 EDT 2001"

Comment 20

[Peter Lubczynski]

Attachment: plugin testcase

Comment 21

[Peter Lubczynski]

My testcase seems to work with plugins. Can someone narrow down the problem here?

Note: The OBJECT tag take a completely different code path for plugins vs.
images vs. subdocuments

Comment 22

[Chris Hubick]

I don't have the flash plugin installed, and am still using build 2001091303 as 
I am not immediately in a position to download a new build.

I don't know if it helps but...
that build does NOT work for the image attachment.
But using the Adobe SVG 3.0 plugin it does work for pixel width and height, and 
works for percentage width, but does not seem to work for percentage height.

Comment 23

[Chris Hubick]

Downloaded 2001092403, plugin scaling now works in all cases I tried :-)  Image 
scaling still does not work.

Comment 24

[Alexandru Savulov]

looks like i have to put this one in my priority queue
pushing to 0.9.7

Comment 25

[Alexandru Savulov]

-> 0.9.9 milestone
(i will try to fix this ASAP)

Comment 26

[Alexandru Savulov]

retargeting

Comment 27

[Alexandru Savulov]

Attachment: proposed patch (works for attributes as well as for CSS properties)

The patch replaces the old kidReflowState.mComputedWidth / Height correction
that was getting the attribute values from the content. (the patch looks a
little bit bizare be cause I repaired the indenting too)

Comment 28

[Alexandru Savulov]

BTW: the proposed patch (attachment 65550 [details]) covers (was tested with):

HTML attribute values: pixel, %
CSS property values: px, em, ex, %

Comment 29

[Marc Attinasi]

Comment on attachment 65550 [details]
proposed patch (works for attributes as well as for CSS properties)

I think you might still set kidDesiredSize.height and kidDesiredSize.width to
NS_UNCONSTRAINEDSIZE, before passing that to ReflowChild and FinishReflowChild
- I believe that it is an output-only argument, but you never know :)  Other
than that, it looks great. sr=attinasi (with the change I mentioned)

Comment 30

[Alexandru Savulov]

Attachment: same patch with the change attinasi requested

same patch with the change attinasi requested

replaces attachment 65550 [details]

Comment 31

[Alexandru Savulov]

Comment on attachment 65652 [details]
same patch with the change attinasi requested

from previous patch

Comment 32

[Peter Lubczynski]

Looks good, but let me run some more plugin tests....

Comment 33

[bora123]

Something happened to DOM style object APPLETS. Applet element do not have a 
DOM style object anymore. This was working fine, please look at bug# 61233. Is 
this related to the fix here somehow?

Comment 34

[Alexandru Savulov]

Comment on attachment 65652 [details]
same patch with the change attinasi requested

r= peter lubczynski (verbal)

Comment 35

[Alexandru Savulov]

fixed on trunk