Closed Bug 2482 Opened 26 years ago Closed 26 years ago

Text inside white background overruns to the right

Categories

(Core :: Layout, defect, P2)

Other
Other
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: rekle, Assigned: karnaze)

References

Details

Attachments

(1 file)

The text on the right side of the page in the white area, is rendering right past the end of the white background. In IE, it stops before the end of the background. Also, the yellow "Quick Search" box overflows to the right.
Assignee: troy → karnaze
table seems to be wider than it should be
This seems to happen on windows jan25 but not on mac jan22.
Setting all current Open/Normal to M4.
Status: NEW → ASSIGNED
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Whiteboard: (04/06) 3jrgm@qlink.queensu.ca -- review blocked (mem leak?)
I can't really check whether this page is alright, because ... 1) Clean boot of Win95 B (P133 Thinkpad) 2) Do a clean unzip of nightly build Win95 opt Apr05 3) Start viewer.exe from DOS command prompt (resource:/res/samples/test0.html loaded) 4) Start Navigator 4.51 (home page www.news.com loaded) 5) Use viewer to go to www.queensu.ca, www.mozilla.org, www.netscape.com 6) Exit viewer.exe At this point, everything is OK (i.e., have a known state, working viewer). 7) Start viewer.exe from DOS command prompt (resource:/res/samples/test0.html loaded) Results: Case 1) Never loads (3 times) Case 2) Loads but takes 1 to 6 minutes, and (apparently) leaks memory everywhere. For example, other applications (e.g. Nav 4.51) have had their memory starved out by viewer.exe (Nav 4.51 toolbar has various (non)painting problems). Windows Explorer uses the wrong fonts. When the page does load, it looks pretty good (ignoring some incorrect fonts that are a likely result of the memory leaks) If I then user viewer.exe to go to www.news.com, www.queensu.ca, www.mozilla.org, www.netscape.com, "everything" seems to return to normal (i.e., viewer.exe has released a whopping pile of memory).
Doh -- left out step (8) above: 8) Point viewer.exe to http://www.download.com/
I tried this also with 1) Apr 01 Win95 opt nightly 2) Apr 06 Win95 opt nightly and got the same results as above. For (1), the "damage" to the NS 4.51 toolbar did not go away when viewer exited (but that is most likely just the chance of which bit of memory got stomped).
*** Bug 4691 has been marked as a duplicate of this bug. ***
Just noting that the original reason for opening this bug still needs resolution, but need to get over this loading problem first. From above: "The text on the right side of the page in the white area, is rendering right past the end of the white background. In IE, it stops before the end of the background. Also, the yellow "Quick Search" box overflows to the right."
The loading issue is covered in bug #4387 (but this page still needs to be checked when #4387 is closed). (I'm not obsessing on this bug, I just happened to bump into the other one ;).
*** Bug 4691 has been marked as a duplicate of this bug. ***
Whiteboard: (04/06) 3jrgm@qlink.queensu.ca -- review blocked (mem leak?)
Okay, so I'm stupid. I tested this with Apr09 win95 opt (post #4382 fix and it worked fine for http://www.prometheus-music.com/gecko/wire4a.html as a test of that fix). For www.download.com, the same problems (above) remain. In fact, this time it caused Nav4.51 to crash (and there is a TalkBack generated report of that crash floating around somewhere now for that crash, FWIW). I will narrow this down to a simple test case to duplicate the slow loading. More later.
Okay, the 'slow loading' bug is *not* related to TABLES or FORMS. I believe it revolves around <FONT FACE>. I'm attaching a test case derived from www.download.com, from which I have removed all of ... <TABLE ...></TABLE>, <TR ...></TR>, <TD ...></TD>, <FORM ...></FORM>, <INPUT ...>, <SELECT ...><OPTION ...><OPTION ...></SELECT>, <MAP ...></MAP>, and <IMG ...> leaving mainly these tags ... <P></P>, <A ...></A>, <FONT ...></FONT>, <SPAN ...></SPAN>, <B>, <I>, <TT>, and <SMALL> So for this test page: (1) initial load is slow, (2) I think it has sucked up a ton of memory, (3) the toolbar for Nav4.51 !! will not repaint (unless I quit viewer), (4) reflow/resize is very slow. (Note: my laptop has 24MB RAM/80MB fixed swap/win95 -- I'm testing with Apr09 viewer Optimized. YMMV). If I s/face=/XXXface=/gi in this page (i.e., make it equivalent to having _no_ FACE attributes for the FONT markup), then this page loads/reflows quickly and my Nav4.51 toolbar can now repaint. Weird, huh?
move to m5
*** Bug 4962 has been marked as a duplicate of this bug. ***
Target Milestone: M5 → M6
Moving to M6.
Okey-dokey ... I have tried this page with Apr28 and May03 win95 opt builds and I no longer experience the slow loading and 'strange side effects' that I noted in April (so consider that gone). Turning back to the original reason for this bug report: if I remember correctly, all the c|net sites have changed their design since this bug was first filed (01/18). I cannot see the two problems originally noted (but in the case of (2) there is no 'yellow "Quick Search"' box anymore). I do seem some problems with the page, but these problems are covered by other bugs: bug #4918 -- 1px height TD are oversized, bug #5218 (among others) -- alignment in TD cells. (Any other issues are minor tweaks for another day). So, this is a long-winded way of saying: this bug is DEAD (WORKSFORME|FIXED).
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Marking worksforme per John's recommendation.
Status: RESOLVED → VERIFIED
With the 5/17 build, this page loads without problems.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: