127514 - document width of 100% not filling iframe

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Chris Casciano]

When comparing 

Reproduction:
View the following document in 2 ways
Stand Alone: http://placenamehere.com/movingNames.shtml
In an Iframe: http://placenamehere.com/

When the document is inside of an iframe it behaves incorrectly. The results
lead me to believe that either the html or body elements with widths of 100% are
being set to something much smaller then the full width of the iframe element.

Symptoms:
1) When first visiting the page in the iframe the background image is not
displayed throughout the full width of the iframe. As the script runs and text
overflows the body width the background gets painted progressively towards the
right of the ifrmae.
2) Elements positioned with percentage values of "left" via javascript are
schrunched to the left side of the iframe. (this is not the case when the page
is viewed standalone)


Perhaps if I get some time I'll make a simplified (and more clear cut) test
case, but this has been bugging me for quite some time and I didn't want to put
off filing the bug any longer.

I've seen this behavior in 0.9.7 & 09.8 on both OS X and win2k (possibly older
behavior), but the page isn't that old) & just confirmemd it was still an issue
with the following nightly:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+) Gecko/20020223

Comment 1

[Christopher Hoess (gone)]

->Frames

Comment 2

[Andrew Schultz]

I see both issues.  The background color not filling the full width (#1) is a
dupe of bug 124090.  The left alignment (#2) goes away if "px" specification of
the style.left is used instead of "%", so this probably a side-effect of #1.

Comment 3

[Chris Casciano]

Well, I don't believe #2 is a result of #1, I think its more that they are both
side effects of the width of the document not being the full width of the frame.

From what I saw of that demonstration of bug 124090 (which i didn't run into
before filing this bug) I'm inclined to think these aren't dupes in the true
sense. In particular it seems that in the other is more a case of reflow after
some interaction then this one is - this one seems broken from the start. But
since neither of these are (or have) simple test cases by any means I wouldn't
put money on on it.

For those reasons I'd be more inclined to mark this as blocking bug 124431 along
side of bug 124090, but you folks do whatever you'd think might get all of this
scrolling=no stuff fixed.

Comment 4

[Andrew Schultz]

The background is screwed up *after* the first "name" is displayed.  To see
this, disable Javascript and reload the page.  Essentially, this page
"interacts" with itself.  Both bugs occur after Javascript changes the
element.style attributes.

Comment 5

[John Keiser (jkeiser)]

scrolling=no -> 1.2 (this could still be a dup)

Comment 6

[Chris Casciano]

Looking at it more closely I was inclined to agree that it was a dupe of bug
124090 after all. BUT, after jumping around some of my favorite dhtml sites with
0.9.9 found a page where this is happening with items placed in pixels
measurements. So either the problem is different then this or 124090 states, or
I've run across an altogether different bug with similar symptoms.

The site in question:
http://xlat.assembler.org/

Once you sit though the nav animation (dreadfully slow in 0.9.9... but I guess
that's something to take up elsewhere) click on the lower left nav item (OE).
You'll find yourself with this page in the upper frame:

http://xlat.assembler.org/0E/index.html

It shows similar behavior as the page at placenamehere.com - The background
(black) shrinks to the area only consumed by the page elements. In fact,
something I didn't notice due to lack of a chance on other page, is that I can't
 get a contextual menu when I right click on the empty areas of the frame
(trying to get to View Frame Source).

Comment 7

[John Keiser (jkeiser)]

fixed with bug 119849

Comment 8

[Kevin Ar18]

Attachment: Ignore Attachment (use as a supporting iframe)

Comment 9

[Kevin Ar18]

Attachment: Some helpful information?

Hope this attachment works.
Anyways, from what I was able to determine, the bug occurs only after changing
the "style.fontSize" to something else.

In addition, the page atually begins by showin the entire background before it
is finished loaded, then once the page is done loaded and has processed the
onLoad then the background messes up.

Comment 10

[John Keiser (jkeiser)]

fixed with bug 119849

Comment 11

[Chris Casciano]

WFM 2002041603/Trunk Build on OS/X