Frame widths are not rendered correctly

VERIFIED WORKSFORME

Status

()

Core
Layout: HTML Frames
P2
major
VERIFIED WORKSFORME
20 years ago
18 years ago

People

(Reporter: Timothy McClanahan, Assigned: Eric Pollmann)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Appears fixed. Right on!, URL)

Attachments

(6 attachments)

(Reporter)

Description

20 years ago
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...

Updated

19 years ago
Assignee: toshok → rickg

Comment 1

19 years ago
Reassigning from toshok to rickg

Comment 2

19 years ago
Reassigning from toshok to rickg

Updated

19 years ago
Assignee: rickg → karnaze

Comment 3

19 years ago
This looks like a legitimate framewidth problem.

Updated

19 years ago
Component: Layout → Macintosh FE

Comment 4

19 years ago
Setting all current Open Critical and Major to M3

Updated

19 years ago
Component: Macintosh FE → HTMLFrames
Product: MozillaClassic → Browser
QA Contact: 4082

Comment 5

19 years ago
Yep, still broken in many ways. March 9 builds

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 6

19 years ago
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.

Updated

19 years ago
Whiteboard: unable to verify with mar 14 builds

Comment 7

19 years ago
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.

Comment 8

19 years ago
Still hosed with March 15 builds; unable to verify properly.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 9

19 years ago
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.
(Reporter)

Updated

19 years ago
Status: VERIFIED → REOPENED
(Reporter)

Comment 10

19 years ago
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)
(Reporter)

Updated

19 years ago
Resolution: FIXED → ---
(Reporter)

Comment 11

19 years ago
With M8 - same behaviour as other Navigators (except M7) - back to the wrong
pixel width for the frame.

Updated

19 years ago
Assignee: karnaze → pollmann
Status: REOPENED → NEW

Comment 12

19 years ago
Reassigning to Eric.

Updated

19 years ago
Target Milestone: M3 → M9

Comment 13

19 years ago
Moved to M9.  M3 is long past.
(Assignee)

Comment 14

19 years ago
Created attachment 1009 [details]
Pixel ruler
(Assignee)

Comment 15

19 years ago
Created attachment 1010 [details]
Measured frame
(Assignee)

Comment 16

19 years ago
Created attachment 1011 [details]
Description frame
(Assignee)

Comment 17

19 years ago
Created attachment 1012 [details]
Title bar frame
(Assignee)

Comment 18

19 years ago
Created attachment 1013 [details]
Working test case
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M9 → M10
(Assignee)

Comment 19

19 years ago
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.
(Assignee)

Comment 20

19 years ago
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!
(Assignee)

Comment 21

19 years ago
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...
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 22

19 years ago
There is not extra pixel now, this is displaying correctly.  To verify, view the
test case marked "working test case".
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 23

19 years ago
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!

Updated

19 years ago
Resolution: WORKSFORME → ---

Comment 24

19 years ago
Clearing WorksForMe resolution due to reopen
(Assignee)

Updated

19 years ago
Status: REOPENED → ASSIGNED
OS: Windows 95 → All
Hardware: PC → All
(Assignee)

Comment 25

19 years ago
Will take a look...

Updated

19 years ago
QA Contact: glynn → petersen
(Reporter)

Comment 26

19 years ago
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.
(Assignee)

Comment 27

19 years ago
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.
(Assignee)

Updated

18 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 28

18 years ago
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!
(Assignee)

Comment 29

18 years ago
Created attachment 3501 [details]
screenshot of working test case

Updated

18 years ago
Status: RESOLVED → VERIFIED

Comment 30

18 years ago
With the latest build (1999121508), I can't reproduce the problem described.
(Reporter)

Updated

18 years ago
Whiteboard: unable to verify with mar 14 builds → Appears fixed. Right on!
(Reporter)

Comment 31

18 years ago
Just tried the latest daily build - works for me now, too, woohoo!!!
(Assignee)

Comment 32

18 years ago
Cool...  :)

Comment 33

18 years ago
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.
(Assignee)

Comment 34

18 years ago
Hello tronster321@hotmail.com, this is because you are using invalid html. See
bug 29749.  This bug (bug 1199) should not be reopened.
You need to log in before you can comment on or make changes to this bug.