Summary: | Images aren't laid out on load inside a position:absolute div | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | mh | ||||||||||
Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> | ||||||||||
Status: | RESOLVED FIXED | ||||||||||||
Severity: | Normal | CC: | ap, mitz, robert, simon.fraser | ||||||||||
Priority: | P2 | Keywords: | InRadar | ||||||||||
Version: | 528+ (Nightly build) | ||||||||||||
Hardware: | All | ||||||||||||
OS: | All | ||||||||||||
URL: | http://wk.ac52.de | ||||||||||||
Attachments: |
|
Description
mh
2011-01-08 09:51:36 PST
Created attachment 78316 [details]
reduced sourcecode with commented out as much elements as possible
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?
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 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). 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.
> 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.
Created attachment 78409 [details]
The image (in case it goes away)
I think is a dupe of 29447. (In reply to comment #9) > I think is a dupe of 29447. My mistake, it's not a dupe - removing the relationship. This appears to be fixed now. Yes, I can't reproduce. |