Bug 50135

Summary: Wrong positioning due to wrong width calculation wrt width:0
Product: WebKit Reporter: crisp <crisp>
Component: CSSAssignee: Pravin D <pravind.2k4>
Status: RESOLVED FIXED    
Severity: Major CC: eric, hyatt, jchaffraix, leviw, mitz, pravind.2k4, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Windows XP   
URL: http://therealcrisp.xs4all.nl/meuk/webkitbug.html
Attachments:
Description Flags
Testcase
none
Patch none

crisp
Reported 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.
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
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
crisp
Comment 1 2010-11-28 14:40:50 PST
Created attachment 74981 [details] Testcase
Pravin D
Comment 2 2012-05-07 09:39:23 PDT
Created attachment 140539 [details] Patch
Pravin D
Comment 3 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.
Eric Seidel (no email)
Comment 4 2012-05-07 11:18:02 PDT
Comment on attachment 140539 [details] Patch This looks reasonable.
Pravin D
Comment 5 2012-05-07 11:19:39 PDT
(In reply to comment #4) > (From update of attachment 140539 [details]) > This looks reasonable. Thnk you
Eric Seidel (no email)
Comment 6 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.
Pravin D
Comment 7 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 :)
Eric Seidel (no email)
Comment 8 2012-05-07 11:28:19 PDT
A pleasure to meet you then. :)
Pravin D
Comment 9 2012-05-07 11:31:06 PDT
(In reply to comment #8) > A pleasure to meet you then. :) The pleasure mine. :)
WebKit Review Bot
Comment 10 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>
WebKit Review Bot
Comment 11 2012-05-07 11:40:28 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.