Open Bug 971368 Opened 11 years ago Updated 2 years ago

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

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

defect

Tracking

()

People

(Reporter: seth, Unassigned)

References

Details

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.
(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.)
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.
Product: Core → Core Graveyard
Product: Core Graveyard → Core

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: seth.bugzilla → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.