Bug 52110 - Images aren't laid out on load inside a position:absolute div
Summary: Images aren't laid out on load inside a position:absolute div
Status: RESOLVED FIXED
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://wk.ac52.de
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2011-01-08 09:51 PST by mh
Modified: 2014-05-27 18:50 PDT (History)
4 users (show)

See Also:


Attachments
reduced sourcecode with commented out as much elements as possible (8.61 KB, text/html)
2011-01-08 10:05 PST, mh
no flags Details
Safari screenshot (17.88 KB, image/png)
2011-01-08 14:35 PST, Alexey Proskuryakov
no flags Details
further reduced test case (445 bytes, text/html)
2011-01-10 02:00 PST, Alexey Proskuryakov
no flags Details
The image (in case it goes away) (3.59 KB, image/png)
2011-01-10 10:40 PST, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description mh 2011-01-08 09:51:36 PST
The images I referre to should appear in the down-left corner of the box.

The bug was observed form different plattforms and different browsers: WinXP with Chrome 8, Linux Debian/Sid with Arora +Webkit 532.4, Midori + WebkitGTK+ 1.2.3 Debian/Squeeze (Qt-webkit 4.6.3 (libqt4-webkit)), Ubuntu 10.04 (Qt-webkit 4.6.2) sowie Fedora 14 (Qt-webkit 4.7.1). It is related only to webkit based browsers, absolutely no problem with other browsers like Opera 11, FF, IE 6/7/8.

Google Instand View (little preview box which you may activate in the Google SERPs) shows the same rendering bug with a website I created. I will provide this URL in private only. So if you like to see this you need to provide an emailaddress where I may sent the respective URL to. 
The example I am posting here is the same sourcecode with commented out as much elements as possible. It is hosted on the same server but on an other domain and probably not indexed yet. So you will not be able to see the Google rendering bug with this example here.

Further: I (and others) could not reproduce this bug localy, it only occurs when the website comes from the server. OTAH, I compared the sourcecode when the bug is triggerd and there is absolute no difference. So I think the server can be excluded as source of the bug.

Now if the bug occurs, you may "heal" it by adding "www." in front of the URL or "/index.html" at the end (but you may as well begin with the "long" URL and the cut off the unnecessary "index.html"). Sometimes it may be sufficient to simply reload the website. And depending on the cirumstances, you may trigger this bug only once. 
- The bigger the sourcecode is and the longer the local machine runs (RAM fragmentation or whatever) the more likely it is you may not heal the bug by reloding the page and the more often you may reproduce the bug. 
- The more the soucecode is reduced and with a fresh booted machine you my reproduce the bug only once.

This is not limited to my computer as you may see in the Google SERPs. 

My personal conclusion is that there is some timing issue which leads to the bug.
Comment 1 mh 2011-01-08 10:05:09 PST
Created attachment 78316 [details]
reduced sourcecode with commented out as much elements as possible
Comment 2 Alexey Proskuryakov 2011-01-08 14:35:36 PST
Created attachment 78331 [details]
Safari screenshot

I'm somewhat confused by the bug description. Is the problem demonstrated by your attached test case (I don't know what a SERP is - is that important for the bug)?

Is the attached screenshot from Safari right, or wrong?
Comment 3 mh 2011-01-08 16:13:01 PST
Am 08.01.2011, 23:35 Uhr, schrieb <bugzilla-daemon@webkit.org>:
 
https://bugs.webkit.org/show_bug.cgi?id=52110
 
 
 
 
 
--- Comment #2 from Alexey Proskuryakov <ap@webkit.org>  2011-01-08 14:35:36 PST ---
Created an attachment (id=78331)
 --> (https://bugs.webkit.org/attachment.cgi?id=78331&action=review)
Safari screenshot
 
So Safari is affected, too.
 
It should look like this:
http://wk.ac52.de/img/3img.png (1)
the same detail taken from your sreenshot shows the tree images way too small, it's the dark yellow pixel on the left edge of the box:
http://wk.ac52.de/img/from_your_screenshot.png (2)
 
Now, if you open safari and connect to http://wk.ac52.de , you see the website like your screenshot (2) shows, if this happens, add "index.html" (which is not necessary normaly) to the address which now looks like: http://wk.ac52.de/index.html and "return" will show you the webpage with correcly rendered images (1).
 
 
I'm somewhat confused by the bug description.
 
I assume my english is not the best, sorry.
 
Is the problem demonstrated by your attached test case (I don't know what a SERP is -
is that important for the bug)?
Taken from the server (sourcecode is exactly the same) the bug gets triggerd. But when I open this file localy, the bug does not show up. I know it sounds strage, but that's how it is.
 
SERP  is "Search Engine Results Page", i.e. the pages you see after you submit a query to Google. Google has a new feature called "Instant View" (IIRC). If you press the magnifier symbol next to one of the links you can see a preview of the linked page. I assume the rendering engine Google uses is webkit based, too. And it shows the same bug.
 
http://wk.ac52.de/img/google.SERP1.png (A) URL sent to your privat email address.
This is a screenshot of a Google SERP showing the preview of a website I created using exactly the sourcecode I sent to you ((A) URL sent to your privat email address). Only difference are the images and all the not commented out elements.) (B) is the magnifier symbol which, when pressed, lets Google create a preview. (C) preview, same sourcecode, 3 missing images. Ok, not really missing, they are as little as the little dark yellow pixels on the screenshot you made.
Why is it important? It proves, that the bug is not related to my machine only. When Google renders the website in question for the little preview, the same bug gets triggerd.
 
 
 
Is the attached screenshot from Safari right, or wrong?
 
 
Your screenshot shows the bug, i.e. the tree images are not rendered in the right dimension but reduced to a few pixels. And they are displaced. Playing with the URL like descibed above will "heal" the result and render the images as they should be. At least that's what happens here and on two other guys computers.
 
If there is any further question please let me know.
 
Thanks.
 
MH
Comment 4 Alexey Proskuryakov 2011-01-10 01:44:01 PST
Confirmed with r75357. This is not a regression from Safari 5.

The images show up too small when loaded from an HTTP server, but they are fine when loaded from cache (this explains why adding www or index.html makes them display all right).
Comment 5 Alexey Proskuryakov 2011-01-10 02:00:24 PST
Created attachment 78382 [details]
further reduced test case

This looks like a timing issue in layout, which is triggered by caching. When the images are cached, their size is 2x2, and when they aren't, they get a correct size.
Comment 6 Alexey Proskuryakov 2011-01-10 02:25:02 PST
> When the images are cached, their size is 2x2, and when they aren't, they get a correct size.

I meant the contrary - when the images are cached, layout is correct.
Comment 7 Simon Fraser (smfr) 2011-01-10 10:22:55 PST
<rdar://problem/8841745>
Comment 8 Simon Fraser (smfr) 2011-01-10 10:40:27 PST
Created attachment 78409 [details]
The image (in case it goes away)
Comment 9 Robert Hogan 2011-08-03 13:18:32 PDT
I think is a dupe of 29447.
Comment 10 Robert Hogan 2011-08-03 13:59:22 PDT
(In reply to comment #9)
> I think is a dupe of 29447.

My mistake, it's not a dupe - removing the relationship.
Comment 11 Robert Hogan 2013-01-29 12:43:28 PST
This appears to be fixed now.
Comment 12 Simon Fraser (smfr) 2014-05-27 18:50:09 PDT
Yes, I can't reproduce.