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+.

Sorry for spam, bad component.

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

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.

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...

.

adt: nsbeta1-

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

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

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.

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

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.

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

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.

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

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

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