Closed Bug 1199 Opened 26 years ago Closed 25 years ago

Frame widths are not rendered correctly

Categories

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

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: tyger11, Assigned: pollmann)

References

(
URL
)

Details

(Whiteboard: Appears fixed. Right on!)

Attachments

(6 files)

Pixel ruler
(deleted), image/gif
Details
Measured frame
(deleted), text/html
Details
Description frame
(deleted), text/html
Details
Title bar frame
(deleted), text/html
Details
Working test case
(deleted), text/html
Details
screenshot of working test case
(deleted), image/gif
Details
The frame widths are not being rendered correctly. I've tried this under Windows 95 & 98, using all frames-capable versions of Navigator, including the recent binaries from Mike Wynhold's site (even the Oct 26 build). I'm not sure that those binaries are using NGLayout, though. ps Windows 98 should be added to the OS list...
Assignee: toshok → rickg
Reassigning from toshok to rickg
Reassigning from toshok to rickg
Assignee: rickg → karnaze
This looks like a legitimate framewidth problem.
Component: Layout → Macintosh FE
Setting all current Open Critical and Major to M3
Component: Macintosh FE → HTMLFrames
Product: MozillaClassic → Browser
QA Contact: 4082
Yep, still broken in many ways. March 9 builds
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The right frame no longer has a scrollbar (my WinNT 3/13 debug build). There is already a bug regarding repainting frameset documents, although that problem is not reported here. The left frame containing the text does not come close to the image frame (which is the issue of the bug) in Nav4.5 but it does in Gecko. This could be a bug in Nav4.5. QA - please verify this in an optimized build on Win95 or Win98.
Whiteboard: unable to verify with mar 14 builds
March 14 builds on win98 - unable to verify as this page is screwed up in new and interesting ways. Top section is garbled, no scroll bars visible anywhere, page is unusable. Something else appears to have broken in the builds. Will have to try March 15 or 16 builds.
Still hosed with March 15 builds; unable to verify properly.
Status: RESOLVED → VERIFIED
Ok, March 17 build frame widths appear to be proper and no scroll bar present, just lots of other frame layout problems as mentioned earlier. Marking this verified and will check to make sure bugs are indeed filed covering other frame layout items.
Status: VERIFIED → REOPENED
With M7, the scrollbar no longer shows up, but by taking a screenshot and measuring the pixels - the width is still not correct. - Reporter (tumbleweed@tumbleweed.net)
Resolution: FIXED → ---
With M8 - same behaviour as other Navigators (except M7) - back to the wrong pixel width for the frame.
Assignee: karnaze → pollmann
Status: REOPENED → NEW
Reassigning to Eric.
Target Milestone: M3 → M9
Moved to M9. M3 is long past.
Attached image Pixel ruler (deleted) —
Attached file Measured frame (deleted) —
Attached file Description frame (deleted) —
Attached file Title bar frame (deleted) —
Attached file Working test case (deleted) —
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
I tried to duplicate the original test case as closely as possible. However, I created a pixel ruler image and placed that in the measured frame to simplify things. This works perfectly for me in viewer. Apprunner is allocating one extra pixel of horizontal space to the left of the image. However, the frameset is still the proper width. Thus, a scrollbar appears on the bottom edge of the frame allowing you to scroll the rightmost one-pixel-edge onto the screen. I can not explain this difference on one pixel and am working on tracking it down.
Pls note that there is a several pixel wide border around the entire webshell window in apprunner. If the background of the test cases is made to another color, it is easier to see the frame size is correct!
After much digging around (Set a breakpoint at nsStyleContext.cpp StyleSpacingImpl::RecalcData() where the margin values get cached, conditional upon the value being 15 twips) I turned up the rather interesting fact that the margins on the body tag are all set to 1 pixel for apprunner and 0 for viewer. Investigating why these default to a different value for apprunner. Further rooting also turned up a workaround: the <BODY> tag takes MARGINWIDTH and MARGINHEIGHT attributes (Not in the HTML 4 or CSS 1 spec that I could find). If you set these to 0 the default margin values (still set to 1 pixel) are overridden and the problem goes away. I'm not suggesting that someone would go do such a thing, but it is interesting...
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 25 years ago
Resolution: --- → WORKSFORME
There is not extra pixel now, this is displaying correctly. To verify, view the test case marked "working test case".
Status: RESOLVED → REOPENED
I just tried this with M10 for Windows (with Win98), and it's not showing a scrollbar, but it's also not the correct width on my test case originally supplied with this bug (http://tumbleweed.net/frametest.html). It's smaller than the specified frame width by 2 pixels. The missing 2 pixels *may* be on the left, in black - I'm not sure - there's some weird black space over there that really shouldn't be, so *something* is definitely going on. Keep digging!
Resolution: WORKSFORME → ---
Clearing WorksForMe resolution due to reopen
Status: REOPENED → ASSIGNED
OS: Windows 95 → All
Hardware: PC → All
Will take a look...
QA Contact: glynn → petersen
Just checked with M11 on Win32 (Win98SE) - still a problem! Current behaviour: Frame no longer shows scollbar (good), but truncates the image (BAD!) - truncates image 1 pixel on left and right sides - can't even tell it's been truncated (must take screenshot and measure). Weird.
After careful consideration, I've decided that I probably won't get this bug in for M12. Currently I have nearly 50 bugs scheduled for M13, so there is a possibility that this bug may need to be moved out farther still.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Sorry, I still do not see any truncation. I did notice that the left and right 1-pixel edges of the image contained in the frame are black, and the background of the page is black, so it is imposible to discern with a screenshot if you are looking at the image or the background. If, however, you look at the test case I have attached above labeled "working test case", the image is yellow and blue - easy to tell apart from the black background. It's also conveniently an image that measures itself. You'll be able to see both the yellow line at pixel 0 and the blue line a pixel 150 in the test case. I'm attaching a screenshot of that one working. I'm marking this worksforme again. Thanks again for being so persistent, and if this bug is being incorrectly closed, please provide me with the screenshot of the testcase working incorrectly in your browser when you reopen it. Thanks!
Attached image screenshot of working test case (deleted) —
Status: RESOLVED → VERIFIED
With the latest build (1999121508), I can't reproduce the problem described.
Whiteboard: unable to verify with mar 14 builds → Appears fixed. Right on!
Just tried the latest daily build - works for me now, too, woohoo!!!
Cool... :)
In M14 on NT4, frames are still not being rendered properly. Go to http://www.tronster.com/index.html and look at the (huge) width of the vertical frame bar. This does not occur in other browsers.
Hello tronster321@hotmail.com, this is because you are using invalid html. See bug 29749. This bug (bug 1199) should not be reopened.
Product: Core → Core Graveyard
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.

Attachment

General

Creator:
Created:
Updated:
Size: