Last Comment Bug 94468 - Bad offset for "position:absolute" DIV when "top" missing
: Bad offset for "position:absolute" DIV when "top" missing
Status: RESOLVED FIXED
[awd:tbl]
: testcase
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: Trunk
: x86 Windows 2000
: -- normal with 1 vote (vote)
: Future
Assigned To: layout.r-and-a-pos
: Hixie (not reading bugmail)
Mentors:
http://derstandard.at
: 96965 195051 199873 204207 233433 (view as bug list)
Depends on:
Blocks: 86310 146455 174322
  Show dependency treegraph
 
Reported: 2001-08-09 03:30 PDT by Helmut Leininger
Modified: 2014-10-11 16:30 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Testcase (499 bytes, text/html)
2001-08-09 12:47 PDT, Mats Palmgren (:mats)
no flags Details
Possible patch (2.92 KB, patch)
2003-09-29 20:37 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Review
Better patch (2.85 KB, patch)
2003-09-30 15:37 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Review
One more tweak.... (2.70 KB, patch)
2003-10-17 20:04 PDT, Boris Zbarsky [:bz]
roc: review+
roc: superreview+
Details | Diff | Review

Description Helmut Leininger 2001-08-09 03:30:33 PDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010807
BuildID:    2001080721

The layout of a 3-columns table is computed by Javascript. In Mozilla, the
contents of col 2 and 3 are shown one beyond the other whereas in Internet
Explorer they are shown side by side.

Reproducible: Always
Steps to Reproduce:
1. http://derstandard.at
2. compare with IE
3.

Actual Results:  wron screen layout

Expected Results:  should show like IE
Comment 1 Grey Hodge (jX) 2001-08-09 11:34:30 PDT
Yep. turning off JS makes the page display fine. The page lays out ok, then the
middle content drops down. 
Comment 2 Mats Palmgren (:mats) 2001-08-09 12:47:35 PDT
Created attachment 45283 [details]
Testcase
Comment 3 Mats Palmgren (:mats) 2001-08-09 12:58:03 PDT
The problem is an absolute positioned element without a specified "top"
property.
Comment 4 Doron Rosenberg (IBM) 2001-08-10 15:03:48 PDT
either an dupe of 72806 or 86310 or 83684, take your pick
Comment 5 Robert Pollak 2001-08-24 16:16:15 PDT
Yes, another dupe of my bug 72806. (Others are: 85545, 91514, 96552)

But: With build 2001082303 on win2k the page looks fine today!
Reporter: Can you please confirm and set this bug to WORKSFORME if possible?
Comment 6 Robert Pollak 2001-08-24 16:19:06 PDT
CC'ing Christoph, the responsible webmaster - he might be interested in the
explanation and the testcase.
Comment 7 Mats Palmgren (:mats) 2001-08-25 11:53:32 PDT
IMO, this is a bug and should not be Evangelized. Compare the testcase with
IE5 and Opera5. It is unreasonable that a missing "top" or "top:auto" means
that the y-position of the box is below the *following* element.
Comment 8 Mats Palmgren (:mats) 2001-08-25 11:56:49 PDT
*** Bug 96965 has been marked as a duplicate of this bug. ***
Comment 9 christoph richter 2001-08-26 11:36:40 PDT
hi,

we changed the code of our website, due more traffic with mozilla buid 
browsers. but i uploaded a mirror of the old site.
have made a test site:
http://derstandard.at/dyn/coop/standard.html
plz change the url.


tried this also on the mac build. there is the same.

and i think bug 85545 and bug 72806 are duplicates. 
Comment 10 anthonyd 2001-12-11 16:35:20 PST
hmm, the rendering i get on IE doesnt look right either.
Comment 11 karnaze (gone) 2002-01-07 09:36:12 PST
Temporarily moving to future until a milestone can be assigned. 
Comment 12 Boris Zbarsky [:bz] 2003-03-05 13:12:23 PST
*** Bug 195051 has been marked as a duplicate of this bug. ***
Comment 13 Boris Zbarsky [:bz] 2003-03-05 13:38:28 PST
The relevant code seems to be
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#871
:

871       // The element would have been block-level which means it would be below
872       // the line containing the placeholder frame
873       if (lineBox != blockFrame->end_lines()) {
874         // The top of the hypothetical box is just below the line containing
875         // the placeholder
876         aHypotheticalBox.mTop = lineBox->mBounds.YMost();
877       }

This is correct if the placeholder is somewhere in the middle of the line... but
in the testcases in this bug, I think the placeholder is becoming the first
frame (or nth frame if there are multiple placeholders) in a line that would
have come _after_ the block.

Do we want to try to put the placeholders in a separate line in this situation?
 Or do we want to adjust this logic to look at the frames in lineBox that come
before aPlaceHolderFrame and use the _top_ of the line box in cases when all
those are placeholders?
Comment 14 Daniel Wang 2003-04-05 01:53:38 PST
*** Bug 199873 has been marked as a duplicate of this bug. ***
Comment 15 Pascal Chevrel:pascalc 2003-05-07 18:26:54 PDT
*** Bug 204207 has been marked as a duplicate of this bug. ***
Comment 16 Pascal Chevrel:pascalc 2003-05-07 18:34:03 PDT
*** Bug 204719 has been marked as a duplicate of this bug. ***
Comment 17 christoph richter 2003-05-08 01:03:38 PDT
okay.

seems that there is an time problem.
i set up bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=204719
yesterday.
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 the other is a duplicate. the site had many changes in 
this time. i would really appreciate that the other bug is reopened.
(i postet this message in both bugs)
Comment 18 christoph richter 2003-09-29 04:20:38 PDT
ähm... is this bug actual?
or can we just close this bug?
no activity....
Comment 19 Karl Vass 2003-09-29 04:33:12 PDT
With version 1.4.1 it occured again ocasionally and unpredictably.
Comment 20 Boris Zbarsky [:bz] 2003-09-29 20:37:45 PDT
Created attachment 132387 [details] [diff] [review]
Possible patch
Comment 21 Boris Zbarsky [:bz] 2003-09-29 20:38:33 PDT
Comment on attachment 132387 [details] [diff] [review]
Possible patch

David, what do you think?
Comment 22 Boris Zbarsky [:bz] 2003-09-30 15:37:16 PDT
Created attachment 132435 [details] [diff] [review]
Better patch

Use IsEmpty().
Comment 23 Boris Zbarsky [:bz] 2003-10-17 20:04:02 PDT
Created attachment 133549 [details] [diff] [review]
One more tweak....
Comment 24 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-10-17 20:38:43 PDT
Comment on attachment 133549 [details] [diff] [review]
One more tweak....

Looks good.
Comment 25 Boris Zbarsky [:bz] 2003-10-18 02:02:47 PDT
fix and testcase checked in.
Comment 26 Boris Zbarsky [:bz] 2004-02-08 11:48:12 PST
*** Bug 233433 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.