Bug 61117 - Inline non-replaced elements are reported to have zero width and height
Summary: Inline non-replaced elements are reported to have zero width and height
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Alexander Pavlov (apavlov)
URL:
Keywords:
: 70252 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-19 02:37 PDT by Alexander Pavlov (apavlov)
Modified: 2011-12-04 23:10 PST (History)
16 users (show)

See Also:


Attachments
Patch (10.97 KB, patch)
2011-11-28 04:35 PST, Alexander Pavlov (apavlov)
no flags Details | Formatted Diff | Diff
Patch (10.47 KB, patch)
2011-11-28 07:05 PST, Alexander Pavlov (apavlov)
koivisto: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Pavlov (apavlov) 2011-05-19 02:37:43 PDT
Firebug reports "auto" for the width and height of inline elements.
Comment 1 Alexander Pavlov (apavlov) 2011-05-24 02:43:24 PDT
@annevk: which of the reported results ("0" vs "auto") do you consider correct? Or do you think it should be something else?
Comment 2 Alexander Pavlov (apavlov) 2011-10-17 21:59:50 PDT
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".
Comment 3 Alexander Pavlov (apavlov) 2011-10-17 22:01:04 PDT
*** Bug 70252 has been marked as a duplicate of this bug. ***
Comment 4 Alexander Pavlov (apavlov) 2011-11-28 04:35:39 PST
Created attachment 116732 [details]
Patch
Comment 5 Antti Koivisto 2011-11-28 06:42:42 PST
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.
Comment 6 Alexander Pavlov (apavlov) 2011-11-28 07:05:50 PST
Created attachment 116753 [details]
Patch
Comment 7 Alexander Pavlov (apavlov) 2011-11-28 07:06:41 PST
(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 8 Antti Koivisto 2011-12-02 05:11:31 PST
Comment on attachment 116753 [details]
Patch

r=me
Comment 9 Alexander Pavlov (apavlov) 2011-12-02 05:33:05 PST
Committed r101787: <http://trac.webkit.org/changeset/101787>
Comment 11 Alexander Pavlov (apavlov) 2011-12-03 07:28:30 PST
(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?
Comment 12 Darin Adler 2011-12-03 16:31:14 PST
(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.
Comment 13 Alexander Pavlov (apavlov) 2011-12-04 02:10:15 PST
(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?
Comment 14 Darin Adler 2011-12-04 13:25:01 PST
Between the last two comments, I landed <http://trac.webkit.org/changeset/101941>, which removes the Mac-specific file and fixes the issue.
Comment 15 Alexander Pavlov (apavlov) 2011-12-04 23:10:24 PST
(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...