The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Future

Status

()

Core
Layout: R & A Pos
RESOLVED FIXED
16 years ago
3 years ago

People

(Reporter: Helmut Leininger, Unassigned)

Tracking

({testcase})

Trunk
Future
x86
Windows 2000
testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [awd:tbl], URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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

16 years ago
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

Comment 2

16 years ago
Created attachment 45283 [details]
Testcase

Comment 3

16 years ago
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

Updated

16 years ago
Summary: Wrong appearance of table (layout computed by Javascript) → Bad offset for "position:absolute" DIV when "top" missing

Comment 4

16 years ago
either an dupe of 72806 or 86310 or 83684, take your pick

Comment 5

16 years ago
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

16 years ago
CC'ing Christoph, the responsible webmaster - he might be interested in the
explanation and the testcase.

Comment 7

16 years ago
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

Comment 8

16 years ago
*** Bug 96965 has been marked as a duplicate of this bug. ***

Comment 9

16 years ago
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

16 years ago
hmm, the rendering i get on IE doesnt look right either.
Whiteboard: [awd:tbl]

Comment 11

15 years ago
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

Comment 14

14 years ago
*** Bug 199873 has been marked as a duplicate of this bug. ***
*** Bug 204207 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 174322
*** Bug 204719 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 166807

Updated

14 years ago
Blocks: 146455

Updated

14 years ago
Blocks: 86310

Comment 17

14 years ago
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)

Updated

14 years ago
No longer blocks: 166807

Comment 18

14 years ago
ähm... is this bug actual?
or can we just close this bug?
no activity....

Comment 19

14 years ago
With version 1.4.1 it occured again ocasionally and unpredictably.
Created attachment 132387 [details] [diff] [review]
Possible patch
Comment on attachment 132387 [details] [diff] [review]
Possible patch

David, what do you think?
Attachment #132387 - Flags: superreview?(dbaron)
Attachment #132387 - Flags: review?(dbaron)
Created attachment 132435 [details] [diff] [review]
Better patch

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)
Created attachment 133549 [details] [diff] [review]
One more tweak....
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
Last Resolved: 14 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.