This bug is in mozilla 1.0 RC2 and probably most others. See the testcase. The iframe and it's table cell are narrower than they should be. Doing almost anything to the remaining elements makes the problem go away (the cell with the iframe expands to take all space not in the left-hand column). From the testcase: <!-- This iframe is too far right. If you put a single character here that isn't in a comment it works, or change 100% to an absolute number (451 (640-149) perhaps), or change frameborder to 1, or set the table's border=1, or remove the cellpadding=0 -->
Same problem with trunk. Once we fix this, we may want to add it to the regression tests
Reassigning to John.
Assignee: attinasi → jkeiser
John - any progress on this? have you looked at the testcase?
Bulk moving P1-P5 un-milestoned bugs to future.
Target Milestone: --- → Future
Is this still valid?
Yes, this is still valid. I've run into another bug with a piece of web software I'm developing, whereby an iframe with "align" attribute defined and enclosed in a "div" tag is rendered with incorrect height and width (usually much smaller than the specified percentage). Remove the div tag, and the iframe renders correctly. Leave the div tag, but remove the "align" attribute of the iframe and mozilla renders the iframe correctly. I've added my comments and a test case to this bug, because they both seem to revolve around the same issue. That is, they both deal with percentage-based width and height values not being applied correctly to an iframe, when certain other conditions are met. Please let me know if this is *not* the case and I need to file a separate bug report.
I'm assuming I've come across a related bug with the following web site: http://www.simlogical.com/ There appear to be some problems translating from percentage geometry to pixel geometry, possibly linked to the presence of scrollbars. My screen in 1280x960px. If I open DOM inspector on the above site and set the DOM inspector browser pane to at least 400px, the computed height of the root HTML node is an integer number of pixels. Below 400px, it is a fractional number of pixel and a vertical scrollbar appears (needlessly). A different problem occurs with the horizontal scrollbar. When "miscpages/newsindex.htm" is displayed in the iframe in the root document, a horizontal scroll bar is present for the containing iframe. When "miscpages/newsindex.htm" is displayed directly, no scrollbar is displayed.
Created attachment 136687 [details] Here is a trivial test case Adding 'style="margin: 0pt"' to the body tag triggers the error.
Comment on attachment 136687 [details] Here is a trivial test case If it were trivial, it wouldn't need to be a zip file (and we could then load it much more easily). (You can always use data: URLs for the IFRAME contents. See http://software.hixie.ch/utilities/cgi/data/data )
Created attachment 136730 [details] Trivial test case (Wow, why did no one tell me about data: before..?)
I just had a play with res/html.css. Removing "inset" from the iframe border style prevents the bug (but looks horrid).
The problem still exists in FireFox 0.8 I'm working on a commercial software system, in a MS house. I've been given the opportunity to, if it's not too much maintenance, change the code such that it works in both IE and Moz. Since the main page is done with iframes within tables, this is obviously a problem. After looking at the test cases: The first one is valid, but with the exception of specifying pixels vs. percentage, I can't work around the bug. The (related) test case seems to work perfectly, but it has nothing to do with tables. Maybe it's related because the frames display properly within another element? The trivial test case seems to work OK as well, also has nothing to do with tables. The reason I feel this works OK (it does display a little funny) is because there is no indication to the outer frame of a size for the inner frame, so it just makes the frame a default size. Frames are not like tables in that they will not expand based on the data. If you change the outer frame to include height="50%" it diplays better. If anyone can suggest a workaround, I'd truly appreciate it.
I thought this: http://www.dabs.com/uk/channels/components/ was another test case - but it only uses forms and tables, not frames. Still, it renders okay in IE6 but not in Gecko/20040307 Firefox/0.8.0+. Is it related?
Another test can be found on http:www.tvfreak.cz Look at left banner under topic "Reklama", which is iframe with width=100% inside table, but the width is greater then column width
It remerged in 1.7RC1 as far as i can tell. http://www.duijvestein.com Does what it should do in Firefox0.8 and moz1.6, but in 1.7RC1 the iframe's right border is set to the page border it seems.
please do not set flags if you don't know how. thanks.
(In reply to comment #18) > please do not set flags if you don't know how. thanks. Would it be ok to set it to "blocking1.8a?" to indicate a request that it be fixed in 1.8? I really need this fixed, and a target milestone of "future" doesn't sound like it will happen this year. Thanks, Nick
OK. This bug, as originally reported, is worksforme. So are all the testcases posted in the bug. Since all comments after comment 6 have nothing to do with this bug, marking worksforme. Please file separate bugs for separate issues.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WORKSFORME
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.