Image documents display images with EXIF orientation with the wrong aspect ratio until they're fully loaded

NEW
Assigned to

Status

()

Core
Layout: Images
5 years ago
5 years ago

People

(Reporter: seth, Assigned: seth)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
As posted by GreenRep in bug 917595 comment 38:

> firefox rotates  http://farm4.staticflickr.com/3826/9028972457_6fa76877df_o.jpg
> correctly, but still(!) gets the *aspect ratio wrong* while loading (without
> cache - ctrl+f5). Well and only shows the lower right part (45°) of the image
> while loading. Very strange.

ImageDocument currently doesn't update its perception of the image's size from layout until the load event. We should figure out a way to do it earlier so that we aren't displaying images with the correct orientation but the wrong size while they're loading, yielding a wrong aspect ratio.
Do we have the EXIF data by the time the nsImageLoadingContent gets an Notify() with SIZE_AVAILABLE?  If so, we could have it notify the image document at that point.
(Assignee)

Comment 2

5 years ago
(In reply to Boris Zbarsky [:bz] from comment #1)
> Do we have the EXIF data by the time the nsImageLoadingContent gets an
> Notify() with SIZE_AVAILABLE?  If so, we could have it notify the image
> document at that point.

Yes, we do have the EXIF information at that point. (In fact, that's the point at which nsImageFrame applies the orientation: in nsImageFrame::OnStartContainer, which is invoked in response to SIZE_AVAILABLE.) So I think that plan should work.

The thing is, that's basically what my original patch from bug 917595 did, and I ran into some problems there with not having access to style information when SIZE_AVAILABLE was sent. (I need to know whether 'image-orientation: from-image' applies.) The comments at the top of ImageDocument::OnStartContainer bear this out. That's the problem that waiting for the load event solved, but to solve this bug I need to take a different approach and do something to make that style information available. (IIRC the frame may not even be constructed at that point, so I'll need to force that too.)
(Assignee)

Comment 3

5 years ago
To clarify, I'm pretty sure that the point at which ImageDocument receives SIZE_AVAILABLE can be different from the point at which nsImageFrame receives SIZE_AVAILABLE. The latter may be getting a replayed event, IIRC.
You can't even be sure you have a frame when onload fires; take the <iframe style="display: none" src="someImage"> case.

nsImageLoadingContent does know whether it has a frame; see nsImageLoadingContent::FrameCreated.  So it could probably notify the document when it has a frame _and_ SIZE_AVAILABLE.
You need to log in before you can comment on or make changes to this bug.