Bug 61117

@annevk: which of the reported results ("0" vs "auto") do you consider correct? Or do you think it should be something else?

annevk's response: ----8<---- If 'display' is inline the 'width' (or 'height') property does not apply. Therefore the computed value needs to be returned. Which would be auto in this case as they are not set and auto is the initial value. Does that help? (See http://www.w3.org/TR/CSS21/visudet.html#the-width-property for when 'width' applies.) ----8<---- Hence, the computed width/height should be "auto" not "0".

*** Bug 70252 has been marked as a duplicate of this bug. ***

Created attachment 116732 [details] Patch

Comment on attachment 116732 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=116732&action=review > Source/WebCore/css/CSSComputedStyleDeclaration.cpp:361 > +static bool isInlineLevel(RenderStyle* style) > +{ > + switch (style->display()) { > + case INLINE: > + case INLINE_BLOCK: > + case INLINE_TABLE: > + return true; > + default: > + return false; > + } > +} > + This information should be available from the renderer.

Created attachment 116753 [details] Patch

(In reply to comment #5) > (From update of attachment 116732 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=116732&action=review > > > Source/WebCore/css/CSSComputedStyleDeclaration.cpp:361 > > +static bool isInlineLevel(RenderStyle* style) > > +{ > > + switch (style->display()) { > > + case INLINE: > > + case INLINE_BLOCK: > > + case INLINE_TABLE: > > + return true; > > + default: > > + return false; > > + } > > +} > > + > > This information should be available from the renderer. Made use of RenderObject::isInline() instead.

Comment on attachment 116753 [details] Patch r=me

Committed r101787: <http://trac.webkit.org/changeset/101787>

This is causing a failure on Lion: http://build.webkit.org/results/Lion%20Intel%20Release%20(Tests)/r101787%20(3165)/svg/css/getComputedStyle-basic-pretty-diff.html

(In reply to comment #10) > This is causing a failure on Lion: > http://build.webkit.org/results/Lion%20Intel%20Release%20(Tests)/r101787%20(3165)/svg/css/getComputedStyle-basic-pretty-diff.html Could I have failed to update a Lion-specific expectation for this test? I have fixed one general and 2 chromium-specific ones. Are there more to fix?

(In reply to comment #11) > (In reply to comment #10) > > This is causing a failure on Lion: > > http://build.webkit.org/results/Lion%20Intel%20Release%20(Tests)/r101787%20(3165)/svg/css/getComputedStyle-basic-pretty-diff.html > > Could I have failed to update a Lion-specific expectation for this test? I have fixed one general and 2 chromium-specific ones. Are there more to fix? Yes, there is. platform/mac/svg/css/getComputedStyle-basic-expected.txt I used the "find" command to find all the copies of this test result. Apparently the Mac version exists because CSS_GRID_LAYOUT is on for Mac and off for other platforms.

(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > This is causing a failure on Lion: > > > http://build.webkit.org/results/Lion%20Intel%20Release%20(Tests)/r101787%20(3165)/svg/css/getComputedStyle-basic-pretty-diff.html > > > > Could I have failed to update a Lion-specific expectation for this test? I have fixed one general and 2 chromium-specific ones. Are there more to fix? > > Yes, there is. > > platform/mac/svg/css/getComputedStyle-basic-expected.txt > > I used the "find" command to find all the copies of this test result. Apparently the Mac version exists because CSS_GRID_LAYOUT is on for Mac and off for other platforms. Ouch... I used the same command and did not find this file. Also, http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/svg/css/getComputedStyle-basic-expected.txt results in "No node /trunk/LayoutTests/platform/mac/svg/css/getComputedStyle-basic-expected.txt at revision 101951". Any clues what's going on here?

Between the last two comments, I landed <http://trac.webkit.org/changeset/101941>, which removes the Mac-specific file and fixes the issue.

(In reply to comment #14) > Between the last two comments, I landed <http://trac.webkit.org/changeset/101941>, which removes the Mac-specific file and fixes the issue. Thanks for handling this, Darin. I should be more attentive next time...