429817 - background-image not working in non-chrome user stylesheets in thunderbird

Status: RESOLVED FIXED

(Thunderbird :: Security, defect, P4)

Description

[Pavlos Touboulidis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041803 Thunderbird/3.0a1pre ID:2008041803

Background images fail to display when they are data urls and the CSS is applied using the stylesheet service. The error console doesn't show any warning or error.


Reproducible: Always

Steps to Reproduce:
1. Install and open Stylish
2. Click the "Write..." button to write a new style
3. Paste the following in the text area and click preview

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

toolbarspring {
  background: red url() repeat !important;
  background-image: url("chrome://messenger/skin/icons/quick-search-clear.png") !important;
  background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAHCAYAAADEUlfTAAAAIUlEQVQImWNgwA3+45P4j03Ff3TJ/9gk0AVQJLAaRZTrANZXFOyxhZAqAAAAAElFTkSuQmCC") !important;
}
Actual Results:  
The background of the toolbarspring next to the main menu turned red but the background image didn't show.

Expected Results:  
It should have displayed the background image (a black "check") over a red color.

Comment 1

[ovidiu]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008050715 Lightning/0.6a1 Thunderbird/3.0a1 ID:2008050715
same

I actually blamed Stylish for such when had issues with some lightning calendar css, but I put this in userChrome.css and see no change. So I'd say it's a bug ..

Comment 2

[Joe Sabash [:JoeS1]]

Marking this a dup of bug 154836
Pavlos, if you disagree, please re-open

Comment 3

[ovidiu]

Not really. may be related somehow, but not dupe IMO. 

1.that is a bug about messages css and images, this is about user css for skins
2.this works on TB 2.0.0.16 very well, but not on trunk (*regression?*)
3.this is not limited to data in my case, but to all images

Retested in version 3.0a2 (2008072418) and even worse:

using userChrome.css and clean TB, no extensions

#folderTree {
  background: red url("out.png") repeat !important;
}

[replace pic with whatever aside userchrome file], 
-not working. goes red but no img. 
-not this, no for file:/// path, not data: ... I basically cannot use img in css ui style anymore.

Note that I tested repeatedly with styles that work like a charm in tb2

reopening 
please further test these with latest trunks

Comment 4

[Boris Zbarsky [:bzbarsky]]

One major change with regard to CSS background images from Gecko 1.8 to Gecko 1.9 is the way we do the security check for loading them.  We used to base it on the document the CSS is applied to; now we base it on the stylesheet the CSS is in.

Which means that the images in question are no longer being loaded by all-powerful chrome, but by whatever principal the user sheet has (file:// for userChrome, no idea for stylish).

Then we end up in nsMsgContentPolicy::ShouldLoad, which allows through loads sourced from chrome:/resource:/about:, but blocks all others.  At the very least, it should probably allow data:, and maybe the check for requesting location should be loosened a bit somehow too.

Comment 5

[Mark Banner (:standard8)]

Triaging according to policy for flags.
https://wiki.mozilla.org/Thunderbird:Release_Driving

Comment 6

[Mark Banner (:standard8)]

Attachment: The fix

Here is the proposed fix:

- Allow requesting locations which are file protocols to load any URI.
- Allow data protocols to be loaded from any context location.

From comment 4 this is what I understand is needed.

Comment 7

[[e-mail]]

Comment on attachment 335574 [details] [diff] [review]
The fix

I don't think this affects SeaMonkey because we bail out earlier (code is #ifndef Thunderbird).

Comment 8

[[e-mail]]

(In reply to comment #7)
> (From update of attachment 335574 [details] [diff] [review])
> I don't think this affects SeaMonkey because we bail out earlier (code is
> #ifndef Thunderbird).
To clarify, file: and data: background images in user*.css load as expected. A data: image in a new message gets turned into a cid: attachment, so this fix only helps SeaMonkey when the start page or a message contains data: images.

Comment 9

[[e-mail]]

I can however verify that the acid2 test displays correctly with this patch applied and with plugins enabled in the message window.

Comment 10

[[e-mail]]

Comment on attachment 335574 [details] [diff] [review]
The fix

>   rv = aContentLocation->SchemeIs("chrome", &isChrome);
>   rv |= aContentLocation->SchemeIs("resource", &isRes);
>+  rv |= aContentLocation->SchemeIs("data", &isData);
> 
>-  if (isExposedProtocol || (NS_SUCCEEDED(rv) && (isChrome || isRes)))
>+  if (isExposedProtocol || (NS_SUCCEEDED(rv) && (isChrome || isRes || isData)))
r=me on this bit, but I still have no way of testing the other code...

Comment 11

[Joe Sabash [:JoeS1]]

> data: image in a new message gets turned into a cid: attachment, so this fix
> only helps SeaMonkey when the start page or a message contains data: images.
> 

This does not happen (conversion to CID) when you use:
<div style="width: 20%; height: 20%; background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAHCAYAAADEUlfTAAAAIUlEQVQImWNgwA3+45P4j03Ff3TJ/9gk0AVQJLAaRZTrANZXFOyxhZAqAAAAAElFTkSuQmCC);" );="" align="right">test</div>

I have a composition in my unsent Ermmm outbox ready to test.
This would be the first time I successfully inserted a background-image in a div or a table, in many years of trying.

BTW the background shows in the composition window, but not in the saved message.

Comment 12

[Joe Sabash [:JoeS1]]

The above with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080825031404 Shredder/3.0b1pre ID:20080825031404

Comment 13

[David Ascher (:davida)]

This seems to fix moz-border-image in Thunderbird chrome (except for extensions, somehow).  This will allow much nicer buttons, so marking blocking-tb3+, and asking for targeting b2 (b1 would be fine, but not necessary).

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 335574 [details] [diff] [review]
The fix

r=dveditz

Comment 15

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/e3756324068f