Closed Bug 94468 Opened 23 years ago Closed 21 years ago

Bad offset for "position:absolute" DIV when "top" missing

Categories

(Core :: Layout: Positioned, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: h.leininger, Unassigned)

References

()

Details

(Keywords: testcase, Whiteboard: [awd:tbl])

Attachments

(2 files, 2 obsolete files)

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
Yep. turning off JS makes the page display fine. The page lays out ok, then the
middle content drops down. 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file Testcase
The problem is an absolute positioned element without a specified "top"
property.
Assignee: asa → karnaze
Component: Browser-General → Layout
Keywords: testcase
QA Contact: doronr → petersen
Summary: Wrong appearance of table (layout computed by Javascript) → Bad offset for "position:absolute" DIV when "top" missing
either an dupe of 72806 or 86310 or 83684, take your pick
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?
CC'ing Christoph, the responsible webmaster - he might be interested in the
explanation and the testcase.
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.
Keywords: 4xp
*** Bug 96965 has been marked as a duplicate of this bug. ***
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. 
hmm, the rendering i get on IE doesnt look right either.
Whiteboard: [awd:tbl]
Temporarily moving to future until a milestone can be assigned. 
Status: NEW → ASSIGNED
Target Milestone: --- → Future
*** Bug 195051 has been marked as a duplicate of this bug. ***
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?
Assignee: karnaze → position
Status: ASSIGNED → NEW
Component: Layout → Layout: R & A Pos
Keywords: qawanted
QA Contact: petersen → ian
*** Bug 199873 has been marked as a duplicate of this bug. ***
*** Bug 204207 has been marked as a duplicate of this bug. ***
Blocks: 174322
*** Bug 204719 has been marked as a duplicate of this bug. ***
Blocks: 166807
Blocks: 146455
Blocks: 86310
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)
No longer blocks: 166807
ähm... is this bug actual?
or can we just close this bug?
no activity....
With version 1.4.1 it occured again ocasionally and unpredictably.
Attached patch Possible patch (obsolete) — Splinter Review
Comment on attachment 132387 [details] [diff] [review]
Possible patch

David, what do you think?
Attachment #132387 - Flags: superreview?(dbaron)
Attachment #132387 - Flags: review?(dbaron)
Attached patch Better patch (obsolete) — Splinter Review
Use IsEmpty().
Attachment #132387 - Attachment is obsolete: true
Attachment #132387 - Flags: superreview?(dbaron)
Attachment #132387 - Flags: review?(dbaron)
Attachment #132435 - Flags: superreview?(dbaron)
Attachment #132435 - Flags: review?(dbaron)
Attachment #132435 - Flags: superreview?(dbaron)
Attachment #132435 - Flags: review?(dbaron)
Attachment #132435 - Attachment is obsolete: true
Attachment #133549 - Flags: superreview?(roc)
Attachment #133549 - Flags: review?(roc)
Comment on attachment 133549 [details] [diff] [review]
One more tweak....

Looks good.
Attachment #133549 - Flags: superreview?(roc)
Attachment #133549 - Flags: superreview+
Attachment #133549 - Flags: review?(roc)
Attachment #133549 - Flags: review+
fix and testcase checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 233433 has been marked as a duplicate of this bug. ***
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: