Bug 43559

Summary: Computed style of an image being loaded has height and width 0px instead of auto (Products don't show on plan-itinteriors.com)
Product: WebKit Reporter: harry <spam>
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: RESOLVED CONFIGURATION CHANGED    
Severity: Normal CC: aestes, ap, bfulgham
Priority: P2 Keywords: HasReduction
Version: 525.x (Safari 3.2)   
Hardware: All   
OS: All   
URL: http://www.plan-itinteriors.com
Attachments:
Description Flags
screenshot
none
reduced test case none

Description harry 2010-08-05 07:25:00 PDT
See summary - that's all there is to it!

I don't know what version this is - but Safari 5 and Chrome 5 are both having issues (tried lots of different versions too)
Comment 1 Alexey Proskuryakov 2010-08-06 06:24:57 PDT
I cannot reproduce this. Here is what I did:
1. Opened http://www.plan-itinteriors.co.uk/
2. Hovered "Products" in site menu bar - a huge submenu appeared.
3. Clicked the first option, "Consul Manager Executive Range".

It seemed that everything loaded correctly.
Comment 2 harry 2010-08-06 06:27:34 PDT
Hi Alexey,

Thanks for your reply.

You should notice on the home page that there are no products (just a few dots)

On other browsers, you'll see the whole product list.

If you then go to another page, and then back again, you'll see that the products appear.

Thanks
Comment 3 Alexey Proskuryakov 2010-08-06 06:30:51 PDT
Thanks for the clarification, I see it now.
Comment 4 harry 2010-08-06 06:31:41 PDT
OK - any ideas? Is there something we can change in the source code?
Comment 5 Alexey Proskuryakov 2010-08-06 06:31:42 PDT
Created attachment 63716 [details]
screenshot
Comment 6 harry 2010-08-06 06:34:59 PDT
that's it!
Comment 7 harry 2010-08-18 02:59:27 PDT
Hi Alexey,

Just wanted to see if there was any updates with regards to this.

Thanks,
Harry
Comment 8 Alexey Proskuryakov 2010-08-23 16:31:59 PDT
Created attachment 65177 [details]
reduced test case
Comment 9 Alexey Proskuryakov 2010-08-23 16:38:12 PDT
The issue here is that a script manipulates the images' width/height before they have finished loading. Firefox returns "auto" in this case, while WebKit returns "0px" - and setting the dimensions back to that makes the image remain 0x0 pixels forever.

This code in captions.js should be made ready for 0px width and height:

			var w = _img.css('width');
			var h = _img.css('height');
			$('.caption',$this).css({'color':o.caption_color,'background-color':o.caption_bgcolor,'bottom':'0px','width':w});
			$('.overlay',$this).css('background-color',o.overlay_bgcolor);
			$this.css({'width':w , 'height':h, 'border':o.border});

Alternatively, the code can be executed when document is loaded, not just ready (in jQuery, the latter means that the document itself has finished loading, but not necessarily its subresources).
Comment 10 Alexey Proskuryakov 2010-08-23 16:39:11 PDT
Something like this should probably do the trick:

			$('.caption',$this).css({'color':o.caption_color,'background-color':o.caption_bgcolor,'bottom':'0px','width':'auto'});
			$('.overlay',$this).css('background-color',o.overlay_bgcolor);
			$this.css({'border':o.border});
Comment 11 Alexey Proskuryakov 2010-08-23 17:03:51 PDT
Chromium folks WONTFIXed the same issue before, see <http://code.google.com/p/chromium/issues/detail?id=20180>.

Per the Chromium bug report, IE behaves the same as Safari, which makes me wonder why/if it doesn't have the same issue on this site.
Comment 12 Alexey Proskuryakov 2010-08-23 17:08:55 PDT
Maybe it's because IE doesn't have getComputedStyle, so jQuery emulates it with currentStyle, which probably has a different behavior. This begins to sound like a jQuery bug.
Comment 13 Ojan Vafai 2010-08-24 10:44:53 PDT
A Firefox nightly returns pixel values from getComputedStyle. The difference appears to be tied to the timing of the load event.

If you listen to window's load event instead of DOMContentLoaded, then Firefox and WebKit get the same results. It appears the Firefox renders the image before DOMContentLoaded fires. Also, in Firefox, if the image is cached, then you get the full-size image. If it's not, then you get a 24px/24px image. Opera always gets the full-size image.

Not sure what the correct fix is here, but WebKit does seem to be the odd one out.
Comment 14 Alexey Proskuryakov 2010-08-24 11:18:51 PDT
Yes, I was sometimes getting "auto" in Firefox, and "24px" other times. Not sure what exactly I was doing differently, but 24px was more common on the reduction.
Comment 15 Ojan Vafai 2010-08-24 12:28:22 PDT
(In reply to comment #14)
> Yes, I was sometimes getting "auto" in Firefox, and "24px" other times. Not sure what exactly I was doing differently, but 24px was more common on the reduction.

Interesting, with the test case in question, I can't seem to get auto out of Firefox 3.6 or 4. I get 24px if I shift+reload and 215px by 174px on a regular reload (i.e. when the image is cached).

I did find a page that consistently returns auto in Firefox 3.6 and 4 if you shift+reload. http://tinyurl.com/24qmgck

It's not clear to me what the correct behavior is.
Comment 16 Ojan Vafai 2010-08-24 14:03:36 PDT
Discussion on #whatwg:
[12:27pm] ojan: annevk5: are there any cases where returning "auto" from getComputedStyle is correct?
[12:27pm] annevk5: yeah
[12:27pm] annevk5: ojan, e.g. for 'top'
[12:28pm] annevk5: iirc
[12:28pm] ojan: annevk5: i'm looking at https://bugs.webkit.org/show_bug.cgi?id=43559. there's a case where WebKit returns 0px and Gecko returns auto
[12:28pm] dbaron: also for other things that are display:none or inside something display:none, I think
[12:29pm] annevk5: ojan, the reason for that is because I aligned with WebKit; Gecko returns the used value there
[12:29pm] annevk5: ojan, oh, that's the reverse
[12:29pm] ojan: it's getting the computed width/height on an uncached image
[12:29pm] annevk5: dbaron, yeah, or where the property is in the special list and does not apply to the element
[12:29pm] ojan: shift+reload http://tinyurl.com/24qmgck to see the difference
[12:31pm] annevk5: ojan, I guess that is because in Gecko the image is treated as inline element so 'width' does not apply and therefore returns the computed value rather than the used value
[12:31pm] ojan: oh, interesting.
[12:31pm] annevk5: ojan, pretty sucky that pages can depend on how browsers generate boxes for replaced elements while loading 
[12:32pm] ojan: this sounds like a scary thing to change (for webkit or gecko) 
[12:32pm] annevk5: sounds like an annoying thing to define too
[12:32pm] annevk5: i guess HTML5 should define that
[12:33pm] • annevk5 checks the rendering chapter
[12:35pm] annevk5: http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#images-0 has the WebKit behavior
[12:36pm] annevk5: http://www.w3.org/TR/CSS21/visudet.html#the-height-property "the percentage or 'auto' (see prose under <percentage>) or the absolute length; 'auto' if the property does not apply"
[12:37pm] annevk5: (and it does not apply with the Gecko <img> model; assuming I guessed all this correctly)
[12:39pm] crash\: there is a Bug for that
[12:39pm] crash\: https://bugzilla.mozilla.org/show_bug.cgi?id=321919
[12:39pm] crash\: pretty much the same problem
[12:40pm] annevk5: crash\, with the same conclusions
[12:41pm] crash\: what does getPropertyValue("width") for <input type=hidden> return?
[12:41pm] crash\: should be auto too, right?
[12:42pm] annevk5: yes
[12:44pm] crash\: maybe I should create a bug and test case for that to clarify that
[12:45pm] annevk5: make a test suite for getComputedStyle, that'd be neat 
[12:47pm] crash\: I can't see where the specs say. what behaviour is right
[12:48pm] annevk5: http://dev.w3.org/csswg/cssom/#dom-window-getcomputedstyle defines it
[12:48pm] annevk5: if anything is unclear please email www-style
[12:52pm] crash\: "If the property applies to the element or pseudo-element and the resolved value of the 'display' property is not none, the resolved value is the used value." for width/height
[12:52pm] crash\: but a not loaded image is not of type display:none;
[12:53pm] annevk5: crash\, no, it's of type inline in Gecko
[12:53pm] crash\: yes, so it should be the computed value
[12:53pm] crash\: so I guess 0px would be right
[12:53pm] annevk5: no, auto
[12:54pm] annevk5: we just discussed this in this channel
[12:54pm] annevk5: I even quoted http://www.w3.org/TR/CSS21/visudet.html#the-height-property
[12:54pm] crash\: ok, since it's inline
[12:55pm] crash\: but when it was replaced it can have a width/height
[12:55pm] crash\: wired
[12:59pm] crash\: ist still dont think "auto" is right 
[12:59pm] crash\: why it can't be 0px and when it can't be replaced and then alt="" is used be "auto"?
[1:00pm] annevk5: crash\, sure, that is what HTML5 defines right now
[1:00pm] annevk5: crash\, but apparently that breaks sites
[1:01pm] annevk5: crash\, again see above for the WebKit bug report
[1:02pm] crash\: ok, that confident me

My read from that is that the spec was written to match WebKit, but that breaks at least this site. Seems like we should change to match Gecko and get the spec changed?
Comment 17 Brent Fulgham 2022-07-11 17:21:28 PDT
Safari, Chrome, and Firefox show the same rendering behavior for this test case. I do not believe any further compatibility issue remains.
Comment 18 Alexey Proskuryakov 2022-07-12 20:21:46 PDT
The attached test bit rotted, but even when fixed, it behaves the same in all browsers.