99289 - Script tag in table makes cells expand incorrectly

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P2)

Description

[Rafael Ebron (:rebron)]

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20010911
Netscape6/6.2

Go to the URL above and you'll see the problem.

Comment 1

[gabriel]

Confirming with linux 2001090712.

Comment 2

[Rafael Ebron (:rebron)]

Do we know what the problem is with this page yet?

Comment 3

[Marc Attinasi]

No idea what the problem is yet. I'll attach the source of the main frame - it
renders pretty fine by itself...

Comment 4

[Marc Attinasi]

Attachment: main frame source (with base href added)

Comment 5

[Marc Attinasi]

Hmm. That main frame source works fine in a frameset too. Definitely need a
reduced testcase to see what is the problem. Any volunteers to help reduce the
page? I think the attachment I made is invalid because the images do not all load...

Comment 6

[Rafael Ebron (:rebron)]

Here's another site with the table's slightly off.  http://www.bu.edu/

Comment 7

[Mai Mai Tsai]

Adding Evangelism to the bug

Comment 8

[Rafael Ebron (:rebron)]

Also a problem on the main Shopping Index page.
http://home.netscape.com/ex/shak/shopping/index.html

and https://www.healthforums.com/start

Comment 9

[Dave Barrowman]

On both http://shopping.netscape.com/deptstores/index.adp and
http://home.netscape.com/ex/shak/shopping/index.html, the page works if you
comment out the line which looks like:

   <SCRIPT LANGUAGE="JavaScript1.2"> DisplayMenu(); </SCRIPT>
I haven't dug into what the function does, but it may be spitting out something
that screws up the table.

Comment 10

[Eric A. Meyer (dead account)]

"Also a problem on the main Shopping Index page.
http://home.netscape.com/ex/shak/shopping/index.html"

This is being triggered, according to my tests in 2001092303/Mac, by a SCRIPT
element in the left-hand table cell.  The "menu" (Auctions/Beauty.../etc.) is
driven out of a script, and if you remove it then the page lays out as intended.
 I'm not sure why this shoudl be so; it might have something to do with what the
script produces, or it could be a rendering bug.  My test case isn't very
minimzed but I'll attach it anyway.

"and https://www.healthforums.com/start"

This page laid out fine in 2001092303/Mac.  Can anyone confirm with a more
recent Windows build?

Comment 11

[Eric A. Meyer (dead account)]

Attachment: Shopping page with script removed (and some styles added)

Comment 12

[Rafael Ebron (:rebron)]

Did a quick QA on the machines that I'm running:

                   6.1 Mac   0.9.4 Branch NT   Trunk Linux
Health Forums         okay     off              okay
BU.edu                okay     off              off
Shopping Index page    off     off              off

With off meaning that content is off to the right when it should be centered. 

Comment 13

[/\/\arcio Galli]

adding marcio

Comment 14

[/\/\arcio Galli]

Adding Vincent Tong for now. I think Vincent have contacts with shopping page
engineers and they may help us. 

Comment 15

[/\/\arcio Galli]

-------------------------------------------------
Guys, I see that we have two issues: (1) a possible real bug and (2) the
evangelism workaround fix since N6.1 is also demonstrating the same problem. 
I created the following testcase, that isolates the problem. 
 
Marc||Eric, please take a look in the following comments: 
(to see if this is a real bug)
--------------------------------------------------------

During the HTML flow, there is one <SCRIPT> DisplayMenu(); </SCRIPT>. This calls
the DisplayMenu function that dynamically write the DIV elements related with
the menu items. Note that they generate a set of itens like: 

<div id="xyz" class="MenuItem" style="width:150">menuItemblabla</div>

Where...

.MenuItem { position: relative; top:0px; left:0px; cursor: "hand";
text-decoration: "none"; color: "#003399"; font-weight: bold; }

If we remove the inline style="width:..." definition, then it works. So the
following testcase is the same version of the shopping page widthout the
style="" property definition. 

Comment 16

[/\/\arcio Galli]

Attachment: testcase includes one of the JS code (DisplayMenu) with changes (removed the style inline property from the menuitens)

Comment 17

[/\/\arcio Galli]

>>> comment about the site www.bu.edu >>>
-----------------------------------------
BTW, the example http://www.bu.edu/ is not the same case. In that case, there is
one table with width="580" and inside the cells, two <img width="580">. Mozilla
is not wrapping these images and causing a [--580--][--580--]. 

Comment 18

[Marc Attinasi]

The width specification, as written in comment <Additional Comments From
/\/\arcio Galli 2001-09-27 15:08> is incorrect and should be ignored. the value
for the width property needs units, as in:

<div id="xyz" class="MenuItem" style="width:150px">menuItemblabla</div>

The bad declaration in the attribute (style="width:150") could be causing other
problems - not sure.

Comment 19

[/\/\arcio Galli]

That's good piece of information. Rafael, so this case the "Shopping" is becomes
official evangelism. Do you know if the new checkin in the shopping code is
related with the addition of that attribute?  Let us know if the workaround
(without the style attribute) works for your case. 

Comment 20

[Mats Palmgren (inactive)]

Attachment: Testcase (shows bug)

Comment 21

[Mats Palmgren (inactive)]

The last testcase (attachment 51257 [details]) shows the bug while it looks good in IE6 and
Opera5 for example. An easy workaround is to move the <SCRIPT>s out of the table
into <HEAD>. Still, I think there is real bug here since it displayes differently
from IE/Opera.

Comment 22

[Rafael Ebron (:rebron)]

Where we are on the website side of things:

Shopping Index page was fixed for 6.1 and looks good in 6.2.

The url provided with the bug http://shopping.netscape.com/deptstores/index.adp
still looks bad in 6.2 but works fine in 6.1.

Not sure what the next steps are here.  Is this a regression that gets fixed or
do I need to go get this fixed via a website change?

Comment 23

[Susie Wyshak]

Please see Bugscape 9958 for further test results.

Comment 24

[Marc Attinasi]

end of milestone shuffle...

Comment 25

[Mats Palmgren (inactive)]

*** Bug 103319 has been marked as a duplicate of this bug. ***

Comment 26

[Marc Attinasi]

Bumping milestone

Comment 27

[Eric A. Meyer (dead account)]

I have a new testcase which may shed some light on this.  My observations are:

* The table cell containing the SCRIPT element will expand to equal the defined
'width' for the TABLE element.
* Not every cell in a table will be affected by this bug, but the leftmost cells
are highly prone to incorrect expansion.
* The expansion can be triggered by following the SCRIPT with an element that
has an explicitly defined width somewhere in the same cell.  In the testcase I
used a DIV with 'width: 10px' but any value for 'width' seemed to cause the
problem.  Placing such a DIV before the SCRIPT did not trip the bug.

I'll attach my testcase immediately; it shows four different ways to trip the
bug (on my system, anyway) and one that doesn't becuase the sized DIV come
before the SCRIPT instead of after.  Bear in mind that the bug is only seen the
first time a page is loaded; once you've reloaded it the layout will be correct.
 This makes testing a real pain as one quits and restarts the browser about a
zillion times.  On the other hand, I did this for about three straight hours
under MacOS9.1 and the browser didn't crash once, which is pretty damned impressive.

In general, given the rising inccidence of developers using small SCRIPTs to
write content into page layouts, this bug ought to get a higher priority. 
Adding myself to the cc: list.

Comment 28

[Eric A. Meyer (dead account)]

Attachment: Five testcases: first four trip bug, last does not

Comment 29

[Eric A. Meyer (dead account)]

I also saw this bug under MacOS as well as Win2KPro, so I've flipped the
Platform/OS to All/All.

Comment 30

[Christine Hoffman]

I tested this page http://shopping.netscape.com/deptstores/index.adp on
11_07_09_trunk build and 11_06_22_0.9.4ec build on Win2000 and I can no longer
see the problem. Can someone else have a look?

Comment 31

[Christine Hoffman]

*** Bug 107584 has been marked as a duplicate of this bug. ***

Comment 32

[shrirang khanzode]

This bug looks fixed now..I tested bug 103319 and that URL is rendering
fine...also I tested out the URL in this bug report and that is fine also..

we can RESOLVE this bug.

Comment 33

[sujay]

oops last comment was made by "sujay"...not "shrir"...

Comment 34

[Marc Attinasi]

The page (http://shopping.netscape.com/deptstores/index.adp) is fixed, but the
bug is still in the code (see testcase at comment #20 and also at comment #28)

So, as written, this is fixed. There is still a problem that we may want to fix
at some time, and there is lots of good info and testcases in this report, so I
am updating the summary and moving out the milestone. Thanks everyone.

Comment 35

[basic]

Attachment: 1 simplified testcase

Comment 36

[basic]

from my testing it seems to me that when a script document.write another
<script> it causes this problem.

Comment 37

[basic]

bug 117695 also has a <script> writing another <script> issue. It might be related.

Comment 38

[Marc Attinasi]

Sending to Karnaze to look at, since this involves table cell width calculations...

Comment 39

[Bernd]

WFM with win98 2002100416, emeyer could you please verify? I think we render
this now exactly as IE. This might has been fixed by the patch for bug 154780. 

Comment 40

[Eric A. Meyer (dead account)]

The testcases appear to be rendered correctly in 2002100703-trunk/Mac, so I
guess that's a verification.

Comment 41

[Bernd]

wfm based on my and emeyers observations