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)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
NEW
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.
Comment 1•11 years ago
|
||
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.
Reporter | ||
Comment 2•11 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.)
Reporter | ||
Comment 3•11 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.
Comment 4•11 years ago
|
||
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.
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
Comment 5•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: seth.bugzilla → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•