OBJECT not using size of containing element when calculating actual size from percentage size

RESOLVED DUPLICATE of bug 106602

Status

()

P2
normal
RESOLVED DUPLICATE of bug 106602
17 years ago
17 years ago

People

(Reporter: russ, Assigned: attinasi)

Tracking

({testcase})

Trunk
Future
x86
Windows 2000
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

When calculating the actual pixel size for rendering OBJECT from a percentage
size, it appears that the calculation is not using the size of its containing block.

Reproducible: Always
Steps to Reproduce:
See examples 2 and 3 in attachment 74757 [details] to bug 131768.

Actual Results:  Size seems to be calculated as a percentage of the window size.

Expected Results:  Size should be calculated as a percentage of size of parent.
(Reporter)

Comment 1

17 years ago
Adding testcase keyword.
Keywords: testcase
I can't reproduce this (unlike bug 131768).  Linux build 2002-03-18-06.
In a Linux CVS build from last night, the object escapes its container in
Example 3, but not Example 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 4

17 years ago
Example 2:
<TABLE border="1" cellspacing="10">
	<TR>
		<TD><OBJECT src="http://mozilla.org/images/mozilla-banner.gif" type="image/gif"
width="100%" style="border: 10px solid red; padding: 10px"></OBJECT></TD>
		<TD><OBJECT src="http://mozilla.org/images/mozilla-banner.gif" type="image/gif"
width="100%" style="border: 10px solid red; padding: 10px"></OBJECT></TD>
	</TR>
</TABLE>

I see the following:
a) The 2 OBJECTs in the table are both about 1150px wide - regardless of the
size of my window or my screen resolution (but my screen res on starting Mozilla
was 1152x864 - coincidence?). This gives me a large amount of horizontal scroll
to see the whole table.
b) Adding width="80%" or width="500" to the TABLE makes no difference to this.
c) The objects escape the table cells, as per bug 131768 (which may be correct
behaviour according to CSS2 - see comments in that bug)
d) I was getting some wierd redrawing effects (parts of the OBJECTs weren't
being redrawn) when scrolling sideways - but this morning all seems to be OK!

Example 3:
<DIV style="width: 300px; height: 300px; border: 4px solid cyan">
<OBJECT src="http://mozilla.org/images/mozilla-banner.gif" type="image/gif"
width="100%" height="100%" style="border: 10px solid red; padding: 10px"></OBJECT>
</DIV>

I see the following:
a) Horizontally, the OBJECT escapes the DIV by the amount I would expect for bug
131768
b) Vertically, the OBJECT fills most of the size of the window
c) If I size my window vertically, the OBJECT stretches vertically accordingly
d) With the top of the OBJECT at the top of the visible area of my window, the
bottom of it stays a fixed distance from the bottom of the area of my window as
I size the window
e) The above point holds true until I size my window vertically small enough
that the status bar starts to disappear. At this point, the OBJECT does not
shrink any more.

I'll attach some screenshots illustrating that.

This is all on 2002031140, Win2K.
Component: Layout → Keyboard Navigation
(Reporter)

Comment 5

17 years ago
Created attachment 74925 [details]
Screenshot - vertical resizing of OBJECT with window

This is the wierdness I talked about for example 3 in my last comment. Note
that the OBJECT has stayed the same size in the first and second screenshots,
and begins to stretch only once the window has reached a certain size (the size
at which the status bar is fully visible).

Updated

17 years ago
Priority: -- → P2
Target Milestone: --- → Future
(Reporter)

Comment 7

17 years ago
Yup, looks like a duplicate. Just tested in RC1 and the problem doesn't happen
in the testcase, so looks like the fix to bug 106602 is a good 'un :-)

Mind you, the testcases still looks wierd - bug 131768 :-(

*** This bug has been marked as a duplicate of 106602 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.