position:absolute table's top/left 'auto' treated as 0 [ABS POS]

RESOLVED FIXED in Future

Status

()

Core
Layout: Tables
P2
normal
RESOLVED FIXED
17 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

({css2, testcase})

Trunk
Future
css2, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: relnote-devel, URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
[Split from bug 51037]

Netscape 4.75 and IE both 5.5 both ignore position:absolute when top and left 
aren't given, but Mozilla acts as if both were zero.  Including top:;left:; in 
the style string has the same result.

Moz 2000091808, Windows 98.
(Reporter)

Comment 1

17 years ago
Created attachment 15265 [details]
testcase

Comment 2

17 years ago
Attaching essentially the same testcase (just cleaned up HTML - content was in 
the HEAD in previous test).

Is this bug dependent or related ot #10209?

Comment 3

17 years ago
Created attachment 15725 [details]
same testcase with cleaner HTML
ccing Buster, Karnaze, Pierre; Assigning to Marc; Taking QA; relnote, [ABS POS].

I twiddled the testcase, and the problem also occurs if you explicitly set
the 'top' and 'left' properties to 'auto'. The problem does _not_ occur if you
position, say, a <div>. I'm guessing this is something to do with the messed
up style contexts we have on table elements, but I'm probably totally wrong...

RELEASE NOTE ITEM
   Mozilla currently does not support the value 'auto' on the 'top' and
   'left' properties on tables. It incorrectly treats them as '0' instead. 
   As a work around, authors are encouraged to polute their markup by wrapping
   positioned <table> elements in a <div>, and positioning that, instead.
   For example, instead of: 
      <table style="position:absolute">  ...   </table>
   ...authors could use:
      <div style="position:absolute"><table>  ...   </table></div>
   This should have a similar effect.
Assignee: pierre → attinasi
Keywords: correctness, css2, relnote, testcase
QA Contact: chrisd → py8ieh=bugzilla
Summary: position:absolute table without top,left treated as 0,0 → position:absolute table's top/left 'auto' treated as 0 [ABS POS]
Target Milestone: --- → Future

Comment 5

17 years ago
Accepting. Ian, you are probably correct about the root of the problem, but I'll
have to look closer when we get a chance.
Status: NEW → ASSIGNED

Updated

17 years ago
Whiteboard: relnote-devel
Nominating nsbeta1 for goal of achieving cross-browser and backward 
compatibility.
Keywords: nsbeta1
QA Contact: ian → amar

Updated

16 years ago
Blocks: 104166

Comment 7

16 years ago
Created attachment 53470 [details] [diff] [review]
hack
That's wrong -- it will break inheritance of 'auto' values and instead cause the
child's value to act like 'auto' rather than inheriting the computed value. 
(Admittedly, there's been some discussion in the working group over whether that
should work, but it does work for us.)

Updated

16 years ago
Blocks: 112836

Comment 9

16 years ago
status? DBaron: if the patch is wrong, what should be done in this case?

Comment 10

15 years ago
Reconfirmed using FizzillaCFM/2002071208. Setting All/All.
Keywords: patch, review
OS: Windows 98 → All
Hardware: PC → All
Keywords: patch, review
Attachment #53470 - Flags: needs-work+

Comment 11

15 years ago
there are two ways to fix the bug IMHO:
- remove the outer table frame and as a consequence the style attributes would
be retrieved for the table itself
- hack around at
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#1031
 and make there a special treatment if a outer-table frame is encountered.
But this bug is only for 'top' and 'left' of auto.  The real problem seems to be
that 'inherit' isn't what you want in this case (for "inherit"-ance from table
to table-outer), since 'inherit' inherits computed values, but you want to
"inherit" the specified value.
(But yes, making the code that looks at 'top' and 'left' know about outer-tables
ought to fix the bug.)
Blocks: 145572

Comment 14

15 years ago
*** Bug 188647 has been marked as a duplicate of this bug. ***

Comment 15

15 years ago
*** Bug 189257 has been marked as a duplicate of this bug. ***
Test case:
   http://www.hixie.ch/tests/adhoc/css/box/absolute/008.html
Blocks: 10209
.
Assignee: attinasi → table
Status: ASSIGNED → NEW
Component: Style System → Layout: Tables
Priority: P3 → --
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

14 years ago
Priority: -- → P3
Target Milestone: --- → Future
Priority: P3 → P2
Still does not work, Mozilla 1.4.

It sounds like the nature of this problem is that, Mozilla internally thinks of
a single Table Element as 2 elements, an outer frame and an inner, and the inner
dismisses the position settings (top, left, right, etc)?

Trying to get a handle on the C++ code linked to... .
Blocks: 220906
Blocks: 208274
Depends on: 205790
Fixed by checkin of bug 205790.

However, Ian's testcase still doesn't work because of a z-ordering bug that
should probably be filed if it isn't already...
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
Actually, never mind about the z-ordering bug.  The testcase requires scrolling...

Comment 21

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

Updated

14 years ago
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.