Closed
Bug 18650
Opened 25 years ago
Closed 23 years ago
<BR> causes scrollbars in iframe, but doesn't use up space
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: mahjongg, Assigned: alexsavulov)
References
()
Details
(Keywords: testcase)
Attachments
(4 files, 4 obsolete files)
ad turns up in scrollable box. at the website www.tweakers.net you will find that the main page has an ad in the upper right hand corner that turns up in a scrollable box. This is certainly not intended as the crollbars overlap a big part of the image. This site uses a lot of frames and javascript so it is hard to see for me what is going on by looking at the source, but i guess there is something funny going on with a mismatch of the actual size of the gif and the HTML coded size. Internet explorer renders the page correctly. I used the nightly build of seamonkey with buid ID: 1999111016
URL: www.tweakers.net
Summary: ad turns op in scrollable box
Summary: ad turns op in scrollable box → ad turns up in scrollable box
Comment 2•25 years ago
|
||
Comment 3•25 years ago
|
||
Comment 4•25 years ago
|
||
Updated•25 years ago
|
Assignee: leger → troy
Component: Browser-General → Layout
Whiteboard: [TESTCASE]
Comment 5•25 years ago
|
||
This may look like bug 14827, but I don't think it is. The bug here is that the trailing <BR> in the first IFRAME is causing vertical space (which triggers bug 14827). Bug occurs in build 1999111016 on Windows NT4 sp5. Bug does not occur with IE4 on the same machine.
Updated•25 years ago
|
Status: NEW → ASSIGNED
OS: Windows 95 → All
Hardware: PC → All
Summary: ad turns up in scrollable box → <BR> causes scrollbars in iframe, but doesn't use up space
Comment 7•25 years ago
|
||
To separate this from bug 14827, let's remove the scrolling=no attribute from the testcase. I'll attach a modified test case after this update. Actually, IE does add extra whitespace after the image for the <BR>. Try the testcase I'm going to add. You'll see scrollbars in both iframes. Scroll down in both, you'll see an extra line of height in the top iframe. This seems to indicate that IE people felt that <BR> should add extra vertical whitespace. We don't seem to have made up our mind: 1) In the first frame, we add scrollbars, but scrolling down reveals that no extra space was added to the height. 2) If the height of the first frame in increased by 15 pixels to 75, no extra scrollbars will be added. The real problem seems to be that we assume the <BR> will require extra vertical space when determining if scrollbars are needed, but them we don't actually create extra vertical space for it. We should decide to either follow IE's lead and both reserve and use the whitespace, or go our own way and not do either. Nisheeth, do you have any comments on this?
Comment 8•25 years ago
|
||
Comment 9•25 years ago
|
||
I would say that BR's should behave the same way inside an IFRAME as they do in a top level document. If we create vertical space for BR's in a top level document (I think we do), we should do the same for BR's in an IFRAME. And I agree that we should either reserve and use the whitespace or do neither.
Updated•25 years ago
|
Target Milestone: M14
Comment 10•25 years ago
|
||
I'll try to figure out where the height calculations are going wrong here and why we aren't actually using the space. Marking M14 as a really rough guestimate.
Comment 11•25 years ago
|
||
Resetting QA contact from leger.
Updated•25 years ago
|
Whiteboard: [TESTCASE] → [TESTCASE] (py8ieh:considering for {css1} radar)
Updated•25 years ago
|
Target Milestone: M14 → M17
Comment 12•25 years ago
|
||
Noncritical. Moving to M17.
Comment 13•25 years ago
|
||
Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!
Keywords: testcase
Comment 14•24 years ago
|
||
The testcases now refer to GIFs that 404. We need to remake the testcases.
Whiteboard: [TESTCASE] (py8ieh:considering for {css1} radar) → [TESTCASE]
Comment 16•24 years ago
|
||
This bug has been marked "future" because the original netscape engineer working on this is over-burdened. If you feel this is an error, that you or another known resource will be working on this bug,or if it blocks your work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M21 → Future
Comment 17•23 years ago
|
||
Bulk reassigning form bugs to Alex
Assignee: pollmann → alexsavulov
Status: ASSIGNED → NEW
Comment 18•23 years ago
|
||
Attachment #2819 -
Attachment is obsolete: true
Attachment #2820 -
Attachment is obsolete: true
Attachment #2823 -
Attachment is obsolete: true
Attachment #2896 -
Attachment is obsolete: true
Comment 19•23 years ago
|
||
Comment 20•23 years ago
|
||
Comment 21•23 years ago
|
||
WORKSFORME, build 2002-02-22-03 on Windows 98 SE.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Whiteboard: [TESTCASE]
You need to log in
before you can comment on or make changes to this bug.
Description
•