Closed Bug 95107 Opened 23 years ago Closed 23 years ago

Tables ignore width tag (in %age) if greater then required render width

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Platform:
Sun
Solaris
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mackking, Assigned: karnaze)

References

(
URL
)

Details

Attachments

(1 file)

testcase showing 6.x working properly
341 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.3) Gecko/20010806 BuildID: Mozilla 0.9.3 for Sparc Solaris 2.8 as downloaded from mozilla site When rendering a table that has a width tag greater then the required width to render the table's content, the table only gets rendered to the width of the content itself. If the width %age is less then the width of the content, then the width tag does take affect and the content is wrapped to fit within the indicated table width. Examples of this behaviour can be seen on Slashdot.org: News item titles that are shorter then the table cell that defines the center column of content will only have the green background color to the end of the title itself and not to the edge of the center cell. Have attempted this on Win 98 & NT(sp6) with Mozilla 0.9.3 and the problem does NOT appear on those platforms. Reproducible: Always Steps to Reproduce: 1. Load http://www.slashdot.org/ Actual Results: Page loads but any content rendered in a table defined with a width tag bigger then the content's width only gets rendered at the content's width. Expected Results: Table should render to width specified in width attribute. HTML Snippet: <html> <head></head> <body> <table width=100%> <tr><td bgcolor=red>This will render narrow.</td></tr> </table> <table width=1000> <tr><td bgcolor=red>This table will render wide.</td></tr> </table> <table width=20%> <tr><td bgcolor=red>This will be shrunk and wrapped to given width %age</td></tr> </table> </body></html>
I don't see this with linux build 2001-08-12-06. Solaris-specific?
Some more info that may be pertinent(??)... CDE 1.4.2; X11 v6.4.1 When I first tried to run the 0.9.3 load (as downloaded from mozilla.org/releases) it complained about missing libCstd.so.1 so I went out and found a copy and downloaded it and slapped it in my LD_LIBRARY_PATH. I just checked for the bug with my 0.9.2 build I still have lying around (also downloaded from mozilla.org/releases/) and it DOES NOT have the table rendering problem. (When I downloaded the 0.9.2 version it was complaining about libstdc++.so.2.10.0, not libCstd.so.1).
Worksforme on 0.9.3 on Mac OS (2001080214, regular build), 0.9.3 on NT (regular build). And I've checked Internet Exploder 5.0 (Mac), Netscape 4.7 (Mac) and iCab 2.5.1 (Mac) too. I don't see that behaviour anywhere, neither on slashdot or your test-case.
Worksforme on Solaris 2001081310. Testcase and Slashdot look as expected.
OK, this is definitely looking like a dependency thing. I've downloaded a couple other binaries versions and been unable to replicate the problem: (All have been run on the same Ultra 5 runing Sol 2.8 with same LD_LIBRARY_PATH) 0.9.2 (Sol 2.8 binary in Release section) - no problem 0.9.3 #1 (Sol 2.8 binary in Release section) - problem 0.9.3 #2 (Sol 2.7 XLIB binary in Release section) - no problem build 2001081310 (Solaris 2.6) - no problem In an attempt to narrow down the problem library I ran 'ldd' on each of the 4 versions of Mozilla I have: mozilla 0.9.2 mozilla 0.9.3 mozilla 2001081310 mozilla 0.9.3 (Sol 2.8) (Sol 2.8) (Sol 2.6 nightly) (Sol 2.7 xlib) libgkgfx.so libgkgfx.so libgkgfx.so libgkgfx.so libmozjs.so libmozjs.so libmozjs.so libmozjs.so libxpcom.so libxpcom.so libxpcom.so libxpcom.so libjsj.so libjsj.so libjsj.so libjsj.so libplds4.so libplds4.so libplds4.so libplds4.so libplc4.so libplc4.so libplc4.so libplc4.so libnspr4.so libnspr4.so libnspr4.so libnspr4.so libdl.so.1 libdl.so.1 libdl.so.1 libdl.so.1 libgtk-1.2.so.0 libgtk-1.2.so.0 libgtk-1.2.so.0 libgdk-1.2.so.0 libgdk-1.2.so.0 libgdk-1.2.so.0 libgmodule-1.2.so.0 libgmodule-1.2.so.0 libgmodule-1.2.so.0 libglib-1.2.so.0 libglib-1.2.so.0 libglib-1.2.so.0 libXext.so.0 libXext.so.0 libXext.so.0 libX11.so.4 libX11.so.4 libX11.so.4 libsocket.so.1 libsocket.so.1 libsocket.so.1 libsocket.so.1 libnsl.so.1 libnsl.so.1 libnsl.so.1 libnsl.so.1 librt.so.1 librt.so.1 librt.so.1 libm.so.1 libm.so.1 libm.so.1 libm.so.1 libthread.so.1 libthread.so.1 libthread.so.1 libthread.so.1 libpthread.so.1 libpthread.so.1 libpthread.so.1 libpthread.so.1 libc.so.1 libc.so.1 libc.so.2 libc.so.1 libmp.so.2 libmp.so.2 libmp.so.1 libmp.so.1 libaio.so.1 libaio.so.1 libaio.so.1 libaio.so.2 libstdc++.so.2.10.0 libw.so.1 libw.so.1 libCrun.so.1 libCrun.so.1 libCstd.so.1 libposix4.so.1 The only real difference seems to be in which C/C++ library is used.
I see this too with the Solaris 8 / moz0.9.3 build. Perhaps some optimization that is not present in the debug builds is causing this? (wild guess)
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
i attached the snippet of code, and it seem to be working correctly, WORKSFORME.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: