I was looking at this webpage, when I realized part of the functionality is missing in Firefox: http://regex.info/blog/lightroom-goodies/jpeg-quality There are a few boxes with image previews. You can select an output compression level and see the corresponding image and file size. The file size part is missing when viewed in Firefox, but works correctly in Chrome, Internet Explorer and Opera. I see the following error in the Error Console: chart.apis.google.com:443 uses an invalid security certificate. The certificate is only valid for the following names: *.google.com , google.com , *.youtube.com , youtube.com , *.youtube-nocookie.com , youtu.be , *.ytimg.com , *.google.com.br , *.google.co.in , *.google.es , *.google.co.uk , *.google.ca , *.google.fr , *.google.pt , *.google.it , *.google.de , *.google.cl , *.google.pl , *.google.nl , *.google.com.au , *.google.co.jp , *.google.hu , *.google.com.mx , *.google.com.ar , *.google.com.co , *.google.com.vn , *.google.com.tr , *.android.com , android.com , *.googlecommerce.com , googlecommerce.com , *.url.google.com , *.urchin.com , urchin.com , *.google-analytics.com , google-analytics.com , *.cloud.google.com , goo.gl , g.co , *.gstatic.com , *.googleapis.cn (Error code: ssl_error_bad_cert_domain) I'm not 100% sure this is the cause for the missing functionality in the page, but it sounds very likely. This leads to the following questions: 1) Are we being more (too?) pedantic here, or do all the other browsers have a security bug? 2) If this is a generic issue with using charts.apis.google.com, does this mean that all sites using that will be broken or crippled in Firefox? 3) Can we get Google to fix their certificate?

*.google.com only matches one level deep.

According to this: https://bugzilla.mozilla.org/show_bug.cgi?id=495339#c8 Firefox's behavior should match that of the other browsers. But in fact Firefox is BROKEN on this site whereas every other browser WORKS. You can verify by loading one of the chart URLs directly: http://chart.apis.google.com/chart?chtt=File+Size+%28kB%29&chts=FFFFFF&chs=150x356&chds=0,445&chbh=a,1,2&chco=FF0000,202020&chf=bg,s,404040&chxt=r&chxs=0,FFFFFF,11,-1,lt,FFFFFF&chg=0,10,1&chxr=0,0,445&cht=bvs&chd=t:34,0,0,0,0,0,0,0,0,0,0,0,0|0,34,35,43,44,45,49,66,72,80,104,194,445&chma=0,0,0,14& This gives a "This Connection is Untrusted" in Firefox, but WORKS in Chrome, Internet Explorer, etc. If you replace http by https, they will all fail similarly, but the original webpage uses http. If I look closer, it looks like Chrome, IE, etc end up connecting to the HTTP site, whereas for some reason we try to redirect to HTTPS and fail.

After looking with Wireshark, the problem seems to be that we ignore the HTTP part and try to use HTTPS for every Google domain, which fails in instances like these where there are subdomains without a SSL cert.

I bisected this to: The first bad revision is: changeset: 103444:ce222ba667f2 user: David Keeler <dkeeler@mozilla.com> date: Fri Aug 24 14:17:27 2012 -0700 summary: Bug 760307 - Preloaded strict-transport-security site list. r=mayhemer, bsmith