Bug 50135 - Wrong positioning due to wrong width calculation wrt width:0
Summary: Wrong positioning due to wrong width calculation wrt width:0
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows XP
: P2 Major
Assignee: Pravin D
URL: http://therealcrisp.xs4all.nl/meuk/we...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-28 14:39 PST by crisp
Modified: 2012-05-07 11:40 PDT (History)
7 users (show)

See Also:


Attachments
Testcase (1.13 KB, text/html)
2010-11-28 14:40 PST, crisp
no flags Details
Patch (4.92 KB, patch)
2012-05-07 09:39 PDT, Pravin D
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description crisp 2010-11-28 14:39:26 PST
See testcase (also attached); when a blocklevel element is positioned to the right, containing another blocklevel element that has it's width set to 0 but which has a positive padding-left-value, it appears that the zero-width is ignored and the positioning of the containing element is wrong.

Changing the width to a non-zero value doesn't exhibit this behaviour.
Comment 1 crisp 2010-11-28 14:40:50 PST
Created attachment 74981 [details]
Testcase
Comment 2 Pravin D 2012-05-07 09:39:23 PDT
Created attachment 140539 [details]
Patch
Comment 3 Pravin D 2012-05-07 09:45:42 PDT
The issue is this:
When a block parent has a child element with width:0 specified, the width of the parent block is calculated as though the child element's width is not specified and takes the child elements width to set as auto. However the content of the child element will not be painted as the child knows its width is zero. 
The cause is that while checking for width type (fixed, auto , etc), in the case of type fixed , the width value is expected to be positive. The check however does not consider the case when width is zero.
Comment 4 Eric Seidel (no email) 2012-05-07 11:18:02 PDT
Comment on attachment 140539 [details]
Patch

This looks reasonable.
Comment 5 Pravin D 2012-05-07 11:19:39 PDT
(In reply to comment #4)
> (From update of attachment 140539 [details])
> This looks reasonable.

Thnk you
Comment 6 Eric Seidel (no email) 2012-05-07 11:22:18 PDT
Comment on attachment 140539 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=140539&action=review

> Source/WebCore/ChangeLog:1
> +2012-05-07  Pravin D  <pravind.2k4@gmail.com>

Normally contributors write their full names here.
Comment 7 Pravin D 2012-05-07 11:26:38 PDT
(In reply to comment #6)
> (From update of attachment 140539 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=140539&action=review
> 
> > Source/WebCore/ChangeLog:1
> > +2012-05-07  Pravin D  <pravind.2k4@gmail.com>
> 
> Normally contributors write their full names here.

Pravin D is my full name  or atleast how it is in official records :)
Comment 8 Eric Seidel (no email) 2012-05-07 11:28:19 PDT
A pleasure to meet you then. :)
Comment 9 Pravin D 2012-05-07 11:31:06 PDT
(In reply to comment #8)
> A pleasure to meet you then. :)

The pleasure mine. :)
Comment 10 WebKit Review Bot 2012-05-07 11:40:23 PDT
Comment on attachment 140539 [details]
Patch

Clearing flags on attachment: 140539

Committed r116331: <http://trac.webkit.org/changeset/116331>
Comment 11 WebKit Review Bot 2012-05-07 11:40:28 PDT
All reviewed patches have been landed.  Closing bug.