Closed Bug 204719 Opened 17 years ago Closed 16 years ago

if there is a Loong site (KB) and there are divs/tables there are layout erros with javascript


(Core :: Layout: Tables, defect, P2)






(Reporter: webmaster, Unassigned)




(Keywords: testcase)


(6 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)

when theres a long site (>50KB)
and there are tables and divs in there.
and when u write some lines with javascript later in the html (document.write) 
then the positioning of the divs is sometimes wrong.
it occours more often, the bigger and complexer the site is.

Reproducible: Sometimes

Steps to Reproduce:
1. go to and view the big frame
2. i set a better test up. next time

Actual Results:  
the div in the middle is placed behind the right div

Expected Results:  
the divs should be next to another


this bug is little crazy. i always use the version 1.2.1 from Mozilla. and 
thats the only build it functions. there are errors at 7.02 (NS) 1.0, 1.1, 1.3
(not so often) 1.4alpha(often, maybe permananet)

the site functions well in IE,Opera,.....
Attached image screenshot
screenshot made in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
Gecko/20030424 Mozilla Firebird/0.6
this is the snapshot website from the Screenshot.
slightly modified that it works as a stand alone
document.write is not JavaScript engine -- the JS engine knows nothing about
"documents".  That's part of the DOM.

In any case, this is a layout bug; most likely the script execution forces a
reflow of the table and then when more content is added things break.

A minimal testcase could be nice (I understand that it may still have to be kind
of big... does replacing parts of the content with whitespace work?)
Assignee: rogerl → table
Component: JavaScript Engine → Layout: Tables
Keywords: qawanted
QA Contact: pschwartau → madhur
I can reproduce it (Mozilla, Build ID: 2003050610) on WinXP. Strange enough,
within DOM Inspector the page seems to be rendered as I think it was supposed to.
Forget my last comment. I just opened the test URL in DOM Inspector without
opening it in the browser first, the layout was messed up.
sorry. i added it in layout tables and in javascript. though i can select more 
than one. so it only took the last

i can set up a small testcase maybe tomorrow. i wait 4 an input of another 
person. think he also had a testcase up.
dupe of bug 204207 or bug 204026
confirmed with build 2003050509 WinXP.
Ever confirmed: true
*** Bug 204722 has been marked as a duplicate of this bug. ***
Christoph, bug 94468 is the oldest report on your site and has a testcase, I saw
other related bug reports, I'll link them to 94468 as dependencies.

*** This bug has been marked as a duplicate of 94468 ***
Closed: 17 years ago
Resolution: --- → DUPLICATE
*** Bug 204026 has been marked as a duplicate of this bug. ***

seems that there is an time problem.
this shall be a duplicate of bug 94468.
this is another bug. the old one depends really on html. not so much on js.

the new bug is only a bug of document.write and a buffer that seems to be too 
small, or do not get bigger at needed time or so.

so i dont think, that this is a duplicate. the site had many changes in this 
time. i would really appreciate that this bug is reopened.
(i postet this message in both bugs)
It looks like it really is a duplicate bug 94468, if I change:
#ivw {position:absolute;}
in the file "standard.html" to:
#ivw {position:absolute;top:0px; left:0px;}
then everything works fine.

-> verified dupe
i cannot reproduce ur steps.
i changed that line from your post in the html file.
and the error also comes....

i tied it on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a)
Gecko/20030424 Mozilla Firebird/0.6
heres the site with the #ivw qithout the top and left and it functions well.
we changed a JS that it doesnt write some document.write code in the site.

this is a unwanted turnaround (but we need to do so for our users)
i reopened the bug.
your verification must be wrong.
i added a snapshot where it functions,but your solution is not applied.
also we changed the code of an 'contentad' that there is no document.write in 
Mozilla. and now it functions well.
i changet it to reopened. hope this is not bad. if so, tell me and i wont do 
it again.
Resolution: DUPLICATE → ---
CCing Pascal and Mats Palmgren to comment about the bug reopening.
OK, it's probably more than one bug lurking here.
Attached file Standalone testcase
It seems to be a timing problem in table sizing. Sometimes the table is to wide

causing overlap with the absolute-positioned text to the right. It is fairly
repeatable with a 5 second pause. If you don't pause, the problem never occurs.
Attached image Screenshot of testcase
It seems that the testcase isn't reproducable when loading it from Bugzilla.
Try saving it to a file. This is what it looks like when the problem occurs.
Keywords: testcase
this is a stripped testcase. i stripped some code.
removing "KW: qawanted" since we have some good testcases in here 
Keywords: qawanted
Priority: -- → P2
Target Milestone: --- → Future
tested the stripped testcase (created-TS: 2003-05-09 03:07:56). the bug is not
resolved in version 1.4 final
tested the stripped testcase (created-TS: 2003-05-09 03:07:56). the bug is not
resolved in version 1.5 alpha.
if u delete the big picture in the left div, the site works. it has something to
do with the document.write.
tested the stripped testcase (created-TS: 2003-05-09 03:07:56). the bug is not
resolved in version 1.5 beta (2003082704).
there are always some meta-bugs, to know what to do.
is there such a 'bug' also für js/divs?
we are now working on a reprogramming of our page due to no help and resolving 
from bugzilla for a long time.
i post when we have updated the site.
Actually, this is almost certainly bug 175364 -- if you have the pause we lay
out, and then when the placeholder moves to the final position the abs pos frame
is not affected....

Marking dependent for now.

Christoph, this will be fixed as we proceed with some architecture changes, but
the fix is not exactly easy, which is why it has not happened yet...
Depends on: 175364
*** Bug 223009 has been marked as a duplicate of this bug. ***
Attachment 122754 [details] is not using static positioning, so this is nothing to do with
bug 175364.

In that testcase, the table is 511 pixels wide (>500 because of the border, I
guess) and the body has an 8px left margin. So it's no surprise that the right
edge of the table overlaps the text positioned at 510px horizontally.
Someone should take another look at the original motivation for this bug and see
if it's valid or not.
Mats could you please look at it again, the url is wfm
WFM, 2004-11-15-06 trunk Linux.
WFM, 2004-11-16-06 trunk Windows XP.

Closed: 17 years ago16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.