Closed Bug 451784 Opened 14 years ago Closed 14 years ago

Background image of major update billboard (Firefox 2.0=>3.0) not shown when pref for "Load images automatically" is set to false

Categories

(www.mozilla.org :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: whimboo, Assigned: sgarrity)

References

Details

(Whiteboard: [MU?])

Attachments

(2 files)

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

If you set the following pref to false than the background image of the major update billboard is not shown. See the attachment how it looks like.

Steps:
1. Create a fresh profile
2. Open preferences and go to Content
3. Disable "Load images automatically"
4. Start the update check

It seems that the background is not loaded because its a regular HTML file. At least it looks odd for users who have this pref disabled.
Looks odd but for the users that actually use this it may very well be the preferred behavior
OS: Windows Vista → All
Hardware: PC → All
Whiteboard: [MU?]
Is there any way to force this though? If we use data URIs, would that make the images load?

I disagree that those users would prefer it. Most users won't know that the window has a web page embedded in the first place. Expected behavior for all users is showing graphics.
When I stated "preferred" behavior I was referring to those that don't want to download the image due to bandwidth usage... most people don't set that pref and those that do in my experience do so to lessen the bandwidth needed to load a page, etc.

I agree regarding expected behavior and as far as whether the background image is displayed with a data uri I don't know but suggest giving it a try.
Depends on: 451807
Depends on: 451808
No longer depends on: 451808
No longer depends on: 451807
Using the inline data url scheme for the images seems to get around with this issue (is that a separate bug? If I don't want to load images, I probably don't care if they are data-encoded or not).

I'll add the images as data-encoded.
(In reply to comment #4)
> I'll add the images as data-encoded.

Done in r17890. Please test - everything should load but the bullet images (which are from the template - I figure that's fine - looks ok without them).
Steven, when this will be live?
(In reply to comment #6)
> Steven, when this will be live?
It's in trunk now. Should I push to stage so John can push to production?
(In reply to comment #4)
> Using the inline data url scheme for the images seems to get around with this
> issue (is that a separate bug? If I don't want to load images, I probably don't
> care if they are data-encoded or not).
I believe the permissions.default.image pref is specifically to prevent downloading images that are not part of the document though that would best be answered by the owner of the functionality. If it were implemented as you suggest I'm not sure if it would be possible to workaround this issue with the remote page used in the application update wizard... we should probably prevent the loading of images as you suggest (e.g. If I don't want to load images, I probably don't care if they are data-encoded or not)
Pascal, you'll likely need to make these changes for other locales as well.
Actually, I'm a liar because Steven did this the right way in the stylesheet that all locales use. ;)
Let's get a new bug on file for comment 4 and comment 8. I'm going to move this one to the mozilla.com component.
Component: Application Update → www.mozilla.com
Product: Toolkit → Websites
QA Contact: software.update → www-mozilla-com
Version: 1.8 Branch → unspecified
Assignee: nobody → steven
(In reply to comment #11)
> Let's get a new bug on file for comment 4 and comment 8. I'm going to move this
> one to the mozilla.com component.
btw: it wouldn't be the first time that we had functionality that didn't describe fully its use in our UI (e.g. it would be difficult to convey the difference between a page with an image that contains it data encoded vs. a page with an image that is separate from the document in our preferences ui).
Status: NEW → ASSIGNED
(In reply to comment #6)
> Steven, when this will be live?

I've merged this change to Stage - now John or Paul will have to push to production (style/tignish/update.css).
The file is live now (or so Wil tells me...we're having some Kubla troubles this morning so he pushed it himself).
Thanks. I tried to update again with the disabled pref and now the background is visible. I think this bug is fixed now.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Verified FIXED.
Status: RESOLVED → VERIFIED
Component: www.mozilla.org/firefox → www.mozilla.org
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.