Bug 13882 - Arch Linux Logo Layered Incorrectly
Summary: Arch Linux Logo Layered Incorrectly
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
URL: http://www.archlinux.org/
Keywords: HasReduction
Depends on:
Blocks:
 
Reported: 2007-05-26 02:03 PDT by Vishal Agrawal
Modified: 2022-07-07 12:29 PDT (History)
3 users (show)

See Also:


Attachments
Reduction (663 bytes, text/html)
2007-05-26 02:45 PDT, mitz
no flags Details
Reduction (665 bytes, text/html)
2007-05-26 02:51 PDT, mitz
no flags Details
Make diff return Detach if one style is "floating or positioned" and the other isn't (29.80 KB, patch)
2007-05-26 06:06 PDT, mitz
hyatt: review-
Details | Formatted Diff | Diff
Non-dynamic test that shows the bug. (718 bytes, text/html)
2007-05-28 15:16 PDT, Dave Hyatt
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Vishal Agrawal 2007-05-26 02:03:11 PDT
On the http://www.archlinux.org/ website, the logo for the distro is not displayed properly. At first I thought it was a neat style -- but then i saw the image in Firefox an Ubuntu machine.
Comment 1 mitz 2007-05-26 02:14:13 PDT
This is not a regression. I thought it was because the first time I opened the site in Safari 2.0.4 it rendered correctly, but upon reload it didn't. The same goes for TOT: sometimes it will lay out correctly, but when reloaded it won't.
Comment 2 mitz 2007-05-26 02:45:37 PDT
Created attachment 14732 [details]
Reduction
Comment 3 mitz 2007-05-26 02:51:21 PDT
Created attachment 14733 [details]
Reduction

This really isn't about the special layout ignoring stylesheets.
Comment 4 mitz 2007-05-26 06:06:58 PDT
Created attachment 14734 [details]
Make diff return Detach if one style is "floating or positioned" and the other isn't

Includes change log and layout test. No layout test regressions.
Comment 5 Dave Hyatt 2007-05-28 14:47:21 PDT
Comment on attachment 14734 [details]
Make diff return Detach if one style is "floating or positioned" and the other isn't

I don't want to detach in this case.  We should be able to handle this without having to do a Detach.  (Destroying the entire render tree will make alternate stylesheet switching significantly slower.)
Comment 6 Dave Hyatt 2007-05-28 15:15:53 PDT
The bug is in the block pref width calculation.  Here is a non-dynamic form of the test that shows the layout failure.
Comment 7 Dave Hyatt 2007-05-28 15:16:37 PDT
Created attachment 14762 [details]
Non-dynamic test that shows the bug.
Comment 8 Dave Hyatt 2007-05-28 15:19:02 PDT
Firefox 3 now uses a pref widths system like we do, and as you can see, they fail the non-dynamic test the same way.  The dynamic test still passes in Firefox 3, however, which I can attribute to the fact that they clean up the leftover anonymous block (but we do not).

There are two bugs here really:
(1) We should have cleaned up the anonymous block (which would fix the dynamic case but not the non-dynamic case).
(2) We computed the wrong block pref width.

In order to get block pref widths right, we can't naively use a non-floating child's pref widths.  We have to actually drill into the child to get better results.

I think (1) will be easier, but (2) would of course be more far-reaching and fix some other bugs we have on file in Radar.

Comment 9 Dave Hyatt 2007-05-28 15:27:32 PDT
Note, though, that CSS3 is planning to formally define the definition of intrinsic width, and it is not going to depend on doing a layout.  The spec may actually end up siding with our block pref width result, even though it is "wrong' when compared with WinIE.  This is one reason I had held off adding any more complexity to block pref width.

http://dbaron.org/css/intrinsic/

Comment 10 Dave Hyatt 2007-05-28 15:28:39 PDT
In particular, the note in dbaron's draft:

"This manner of specifying (and implementing) intrinsic width calculations makes it impossible to specify (or implement) ideal behavior for preferred width of blocks containing floats. The goal of this specification is simply to define an approximation that is good enough, and can be interoperably implemented."
Comment 11 Dave Hyatt 2007-05-28 16:07:09 PDT
Doing (1) is even pretty tricky, since you're mid-style resolution.  It's dangerous to make assumptions about your children inline status when you don't even know what's going to happen to kids that follow you.
Comment 12 Alexey Proskuryakov 2010-06-11 16:21:02 PDT
This doesn't seem to occur at this site any more, but the reduction still fails with r60936.
Comment 13 Brent Fulgham 2022-07-07 12:29:33 PDT
Safari, Chrome, and Firefox appear to have identical behavior on both test cases. I don't believe there are any remaining compatibility issues here.