View Full Version : 4.02 s.gif / BLANK_IMAGE_URL

21 Jun 2011, 5:40 AM
This one is driving me crazy...

I have set my Ext.BLANK_IMAGE_URL to point to a valid 's.gif' file on my server accessible via https - I can use relative or absolute pathing to the "Ext.BLANK_IMAGE_URL = 'https://....../s.gif'" or "Ext.BLANK_IMAGE_URL = ../..../s.gif'".

In either case I keep getting the Mixed content (https / http) warning in MIE 7!

I can copy and paste the Ext.BLANK_IMAGE_URL assignment into my browser and it finds the image just fine. I can use ieHttpHeaders and see ExtJS 4.02 requesting the s.gif image and thre response is "200 OK" or "304 not modified" (until I clear cache). Meanwhile a few requests later, ExtJS continues to request s.gif from the www.sencha.com (http://www.sencha.com) site (using http) and generates the Mixed Content Error in my https site!

What am I doing wrong, or is this a bug?

21 Jun 2011, 7:32 AM
Only applies to IE6 and 7, otherwise it uses an embedded gif.

I've done:

if (Ext.isIE6 || Ext.isIE7) {
// Could use path in Ext framework, but seems a little tree specific, also would have to change when
// we change framework version... 'lib/Ext/ext-4.0.*/resources/themes/images/default/tree/s.gif'
Ext.BLANK_IMAGE_URL = this.webRoot + '/resources/images/s.gif';

But not really tested it yet.
webRoot in my example is 'Altus', so I'm not specifying http or https.

As I say, not tested it yet, since not using SSL for our current pilot.


21 Jun 2011, 7:38 AM
Didn't think about conditionally setting BLANK_IMAGE_URL, nice idea!

My problem is in IE7 when I need to set BLANK_IMAGE_URL and it still doesn't work!



21 Jun 2011, 7:50 AM
The only place I can see it referenced is in Ext-more.js:

BLANK_IMAGE_URL : (isIE6 || isIE7) ? 'http:/' + '/www.sencha.com/s.gif' : 'data:image/gif;base64,R0lGODlhAQABAID/AMDAwAAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==',

So you say that it requests your s.gif once or twice, then decides to go for the sencha one?

21 Jun 2011, 8:10 AM
Just tested my pilot site in IE7 over HTTPS and didn't get any warnings.
We're proxying through Apache to IIS so that could be a factor I suppose.