Closed Bug 522850 Opened 15 years ago Closed 1 year ago

HTML:Img doesn't always retain the correct properties in a XUL window

Categories

(Core :: XUL, defect)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mozilla.bugs, Unassigned)

References

Details

Attachments

(3 files)

Using the testcase from Bug 519390:

1. Go to http://alyoung.com/ and open the Media Tab in Page Info.
2. Select "http://alyoung.com/News/RSS_Feeds/RSSLogo.jpg"

The image does not scale correctly, because the width element retains it's naturalWidth and refuses to assume any smaller width.  Having talked to Mook, he suggested "something is confused that's specific to having html:img in xul, not xul:image in xul, or html:img in html."

I have a temporary solution for Bug 519390, but we should fix this and probably fix it first.  Also, if we fix this, Bug 519390 may fix itself.
The other attachments are references, this one demonstrates the bug.
Also reproducible on Mac OSX 10.6 with FF 3.6b1.

My Windows build id: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091017 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091017051221
OS: Windows Vista → All
Hardware: x86 → All
OS: All → Windows Vista
Hardware: All → x86
When min-width is set (either in the code or by script) to 1px, the image assumes the correct proportions.
OS: Windows Vista → All
Hardware: x86 → All
It has been a very long time, but someone while looking through MXR found that the Image was inheriting its natural width rather than its defined width in the XUL context.  It this parameter was changed to the defined width then the problem would be fixed.

Also when we commit the change, then we need to remove the hack for Bug 519390 in pageInfo.css in the same changeset.
Yes!  Finally, there is use for keeping the endless logs that I do; here is the conversation I just referred to:

[2009-10-21 13:30:30] <tmyoung> How it decides to resize them, I'm trying to isolate what code it problematic with https://bugzilla.mozilla.org/show_bug.cgi?id=522850
[2009-10-21 13:30:46] <Enn> tmyoung: you're looking for the code in nsFrame::BoxReflow and so on
[2009-10-21 13:31:42] <Enn> tmyoung: the image's intrinsic width is being used as the minimium width
[2009-10-21 13:31:55] <tmyoung> That's what I guessed.
[2009-10-21 13:34:07] <tmyoung> Thank you
[2009-10-21 13:34:10] <Enn> tmyoung: dbaron may know why
[2009-10-21 13:35:01] <Enn> tmyoung: note that nsImageFrame::GetMinWidth actually returns intrinsicsize.width
> [2009-10-21 13:35:01] <Enn> tmyoung: note that nsImageFrame::GetMinWidth
> actually returns intrinsicsize.width

This part is correct, since that's the min-intrinsic width for an image....

The real problem is that XUL layout assumes that things can't (or don't want to) shrink below their min-intrinsic width no matter what styles are applied, which is an incorrect assumption for at least replaced elements.
I quickly checked the reduced testcases again, and Firefox no longer loads them since Firefox detects that they are Remote XUL which is now disabled by default.  If someone plans on using the above testcases for testing or development, he or she will need to modify them to open somehow (though I'm not sure if there is a way to achieve that) or build a local version of Firefox that will open them.
The images they used are broken anyway.
At this point, the best way to test the bug is to disable the patch for Bug 519390 in someone's local instance of Firefox, which should be very easy for a developer but not as easy (I think) for someone who can't compile Firefox.  Another advantage to testing this that way is the developer wont need to remove it later in another bug/patch--so we kill two birds with one stone.
Severity: normal → S3

This works with flexbox emulation.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: