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

Status: VERIFIED FIXED

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

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Billboard without a background image

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.

Comment 1

[Robert Strong (they/them - no direct email)]

Looks odd but for the users that actually use this it may very well be the preferred behavior

Comment 2

[Samuel Sidler (old account; do not CC)]

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.

Comment 3

[Robert Strong (they/them - no direct email)]

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.

Comment 4

[Steven Garrity [:sgarrity]]

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.

Comment 5

[Steven Garrity [:sgarrity]]

(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).

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Steven, when this will be live?

Comment 7

[Steven Garrity [:sgarrity]]

(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?

Comment 8

[Robert Strong (they/them - no direct email)]

(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)

Comment 9

[Samuel Sidler (old account; do not CC)]

Pascal, you'll likely need to make these changes for other locales as well.

Comment 10

[Samuel Sidler (old account; do not CC)]

Actually, I'm a liar because Steven did this the right way in the stylesheet that all locales use. ;)

Comment 11

[Samuel Sidler (old account; do not CC)]

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.

Comment 12

[Robert Strong (they/them - no direct email)]

(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).

Comment 13

[Steven Garrity [:sgarrity]]

(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).

Comment 14

[John Slater]

The file is live now (or so Wil tells me...we're having some Kubla troubles this morning so he pushed it himself).

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks. I tried to update again with the disabled pref and now the background is visible. I think this bug is fixed now.

Comment 16

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Post-fix screenshot

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED.