Bug 78379

Summary: REGRESSION (r100949): List items are rendered with incorrect height at bu.edu
Product: WebKit Reporter: alheureux
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: mitz, rniwa, robert
Priority: P1 Keywords: InRadar, Regression
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: http://www.bu.edu/shs/wellness
Attachments:
Description Flags
Chrome 17 / Firefox 11 beta / Safari 5.1.3 comparison none

alheureux
Reported 2012-02-10 13:16:05 PST
Created attachment 126568 [details] Chrome 17 / Firefox 11 beta / Safari 5.1.3 comparison This recently showed up with the distribution of Chrome 17 and a bug was filed there. The original bug transcript from the chromium tracker is below as this has been reproduced in Webkit Nightly r107399: Chrome Version : 17.0.963.46 (Official Build 119351) (OS X and Windows) URL : http://www.bu.edu/shs/wellness/ Behavior in Safari 4.x/5.x: Works as expected Behavior in Firefox 3.x/4.x: Works as expected What steps will reproduce the problem? 1. Create an unordered list with nested li/a tags 2. 3. What is the expected result? Equal height list items What happens instead? First list item is rendered with proper height, remaining are incorrect. Inspector identifies styles that should be applied but does not actually show the styles in that declaration. Attached screenshot shows Chrome 17, Firefox 11 beta, Safari 5.1.3. Chrome 16 rendered this list as FF/Safari. In the screenshot there is an element.style declaration listed, this was manually added via the inspector while testing and does not affect the page rendering/layout.
Attachments
Chrome 17 / Firefox 11 beta / Safari 5.1.3 comparison (754.84 KB, image/png)
2012-02-10 13:16 PST, alheureux 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2012-02-10 21:35:45 PST
<rdar://problem/10848286>
Robert Hogan
Comment 2 2012-02-11 02:30:11 PST
*** This bug has been marked as a duplicate of bug 76465 ***
alheureux
Comment 3 2012-02-11 07:30:44 PST
I'm curious what from that bug is the duplicate here. The markup of the example given here does not include any empty elements. Is it more that the solution for the other bug solves this problem?
Robert Hogan
Comment 4 2012-02-12 11:36:30 PST
(In reply to comment #3) > I'm curious what from that bug is the duplicate here. The markup of the example given here does not include any empty elements. Is it more that the solution for the other bug solves this problem? Here is a reduction: <!DOCTYPE html> <style> #list {border-bottom:1px dotted; border-top:1px dotted;} #list li {display:inline; line-height:1.3em;} #list li span {display:block; border-bottom:1px dotted; border-top:1px dotted;} </style> <body> <ul id="list"> <li> <span>Item One</span> </li> <li> <span>Item Two</span> </li> </ul> </body> </html> There's an extra empty linebox getting created for each list-item in WebKit. This should only get created if you put some text after the </span> tag - bug 76465 fixes this by avoiding the creation that line box unless there *is* some text.
alheureux
Comment 5 2012-02-14 08:06:33 PST
(In reply to comment #4) > (In reply to comment #3) > > I'm curious what from that bug is the duplicate here. The markup of the example given here does not include any empty elements. Is it more that the solution for the other bug solves this problem? > > Here is a reduction: > > <!DOCTYPE html> > <style> > #list {border-bottom:1px dotted; border-top:1px dotted;} > #list li {display:inline; line-height:1.3em;} > #list li span {display:block; border-bottom:1px dotted; border-top:1px dotted;} > </style> > <body> > <ul id="list"> > <li> > <span>Item One</span> > </li> > <li> > <span>Item Two</span> > </li> > </ul> > </body> > </html> > > There's an extra empty linebox getting created for each list-item in WebKit. This should only get created if you put some text after the </span> tag - bug 76465 fixes this by avoiding the creation that line box unless there *is* some text. Thanks very much Robert, I get it now. Here's to hoping it finds its way to Chrome soon and that Safari misses it =\
Note You need to log in before you can comment on or make changes to this bug.