200089 - bad computed style width for table centered with 'margin: auto'

Status: RESOLVED WORKSFORME

(Core :: DOM: CSS Object Model, defect)

Description

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

1. launch mozilla
2. open http://daniel.glazman.free.fr/tmp/table_computed_width_problem.html

Expected result: the computed width of each table should be 300px
Actual result: the computed width of the centered table is not 300px

I selected "Style System" for the Component but it could also be "Layout"
or "Layout Tables"
This bug is a MAJOR bug from an embedding point of view since it breaks table
resizing when the table is centered. AFAIC, this bug should be nsbeta1+ and
topembed+. It should also be EDITORBASE+.

Comment 1

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Sorry for spam, bad component.

Comment 2

[[e-mail]]

uhh... sorry for spam. i'm not sure why it accepted that collision.

Comment 3

[Bernd]

Obviously the returned size is the size of the outer table frame. While what you
would like to get is the inner table frame size.
table_outer_width= margin_left + inner_table + margin_right

I thought Boris did fix it along with bug 98159.

Comment 4

[Boris Zbarsky [:bzbarsky]]

See bug 98159 comment 5.  I explicitly did not switch to using the inner table
frame because I was under the impression that the computed dimensions of the
outer frame were the ones we wanted.... Apparently that is not the case.

Problem is, we do still want the computed offsets of the outer frame, eg...  So
we can't just switch to computing style on the inner frame.  <sigh>.

Over to DOM style; there is no style system bug here, and no layout bug... The
"correct" fix would be to evaluate every single CSS property, decide whether the
inner or outer frame should be used to compute it, and write something similar
to attachment 64047 [details] [diff] [review], I guess...

Comment 5

[Boris Zbarsky [:bzbarsky]]

.

Comment 6

[Samir Gehani]

adt: nsbeta1-

Comment 7

[Hixie (not reading bugmail)]

This bug would be fixed by making computed style mean computed style too.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Ian, please file a bug on computed style to that effect and add dependencies?

Comment 9

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

This major bug is now more than a year old. It's a blocker for Nvu
since Nvu relies on JS side on computed styles for a lot of operations.
In particular, it messes up table manipulation with the mouse and "layer"
positioning.

Proposing a blocker flag for this bug.

Comment 10

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

New test: http://glazman.org/tmp/testComputedMarginLeft.html

Comment 11

[Hixie (not reading bugmail)]

I doubt that fixing this bug would help what you are doing, given that the 
correct answer for the computed value of 'margin-left' on an element with 
'margin-left:auto' is in fact 'auto' per CSS2.1.

Comment 12

[Boris Zbarsky [:bzbarsky]]

See comment 4.  The solution is described there.  It'll probably double the size
of our computed style code, though.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Er, scratch that.  Ian is right -- per the CSS2.1 definition of "computed", you
can't get useful info out of this API anymore, really.

Comment 14

[Boris Zbarsky [:bzbarsky]]

This worksforme.  We must have switched to the inner table at some point....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Pushed a test: http://hg.mozilla.org/projects/cedar/rev/a7546cc8c2ee

Comment 16

[(no longer active)]

Test pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/a7546cc8c2ee