PDA

View Full Version : [Solved]IE6 insecure items warning



sapere
24 Feb 2009, 7:34 AM
I am using quite a few Ext 2.0.2 components to construct a fairly complex UI. I have several panels, grid panels, and toolbars. Our application is running over HTTPS. During IE6 testing we discovered that we are reliably producing a warning about insecure items in one circumstance. Testing with Firefox shows no content was being retrieved over HTTP.

There's quite a bit of code involved and I'm not sure what code to show. The warning dialog occurs right before a panel is expanded, where we're listening on that event and handling it by then loading a JSON store. The URL of the JSON store, though, is a relative URL, so it should be retrieved over HTTPS. Strangely enough, even if I choose not to load the insecure content, all the content loads and renders from the JSON store. So, I'm not even sure what it's complaining about.

I've done quite a bit of searching around the forums for a solution, and there doesn't seem to be one for this. I've set both Ext.BLANK_IMAGE_URL to a local spacer gif and Ext.SSL_SECURE_URL to a blank file and then to true, but this hasn't fixed the problem.

Any suggestions? Thanks in advance.

tryanDLS
24 Feb 2009, 7:58 AM
It's probably a missing image - use Fiddler to see if you get any 404s or maybe something that looks like a request with no file name. This would indicate that you're doing a directory traversal, looking for the default document, which could also be an issue.

sapere
24 Feb 2009, 8:34 AM
I went through all the image URLs in my Ext-related stylesheets, and all references are valid. I double checked that nothing in ext-all-debug was programatically constructing images, too.

tryanDLS
24 Feb 2009, 9:16 AM
Did you look at the traffic with Fiddler?

sapere
24 Feb 2009, 10:16 AM
I tried to look at Fiddler but all I see is 200's loading, no 404's. However, it doesn't appear to be displaying the requests for images, even though I haven't disabled that feature.

Any other suggestions?

sapere
24 Feb 2009, 11:56 AM
I have been able to isolate the issue to the call to JsonStore.load(...), if this helps any.

tryanDLS
24 Feb 2009, 12:30 PM
Could be a problem with the content-type being returned by the server for that request? Or it's not going https.

arthurakay
24 Feb 2009, 12:46 PM
I've never specifically run into this problem with ExtJS, but I have seen it in website's I've built.

In my case we were calling images over HTTP instead of HTTPS (the site was on HTTPS). You'll see in IE that when that warning pops up, the images in question haven't loaded, so that might narrow it down if images are the culprit here.

Images wouldn't show up in Firebug's console, btw, so you may just do a global "Find all" for anything "http:"

tryanDLS
24 Feb 2009, 12:57 PM
Images wouldn't show up in Firebug's console, btw, so you may just do a global "Find all" for anything "http:"

They will be on the Net tab

arthurakay
24 Feb 2009, 1:00 PM
They will be on the Net tab

So they are... I suppose I should be using that more often... ;)

sapere
24 Feb 2009, 1:26 PM
I've never specifically run into this problem with ExtJS, but I have seen it in website's I've built.

In my case we were calling images over HTTP instead of HTTPS (the site was on HTTPS). You'll see in IE that when that warning pops up, the images in question haven't loaded, so that might narrow it down if images are the culprit here.

Images wouldn't show up in Firebug's console, btw, so you may just do a global "Find all" for anything "http:"

Yeah, one of the first things I checked for was any references to resources over http://, but there is no traffic over http://. I should probably double-check that there were no exceptions that occurred when loading the JsonStore.

If I have a JsonStore and I assign a 'loadException' listener, is there a way to determine what the exception was (other than to debug ext-all-debug.js)?

tryanDLS
24 Feb 2009, 1:31 PM
The loadexception handler gets 3 args, including the response from the server, which should get you enough info. If you have to, you can use ext-all-debug.js and set BPs in the Ajax code-it's not hard to follow.

sapere
24 Feb 2009, 2:08 PM
The loadexception handler gets 3 args, including the response from the server, which should get you enough info. If you have to, you can use ext-all-debug.js and set BPs in the Ajax code-it's not hard to follow.

Not according to this documentation (http://extjs.com/deploy/ext/docs/output/Ext.data.Store.html#event-loadexception).

The weird thing is, the 'loadexception' handler is constantly firing, but stepping through HttpProxy.load and HttpProxy.loadResponse with firebug showed that no exceptions were occurring. And since I have no parameters available to the loadexception handler, I have no idea what's wrong and why.

tryanDLS
24 Feb 2009, 2:38 PM
You are misreading the documentation (this will be fixed in next doc rev)

Called with the signature of the Proxy's "loadexception" event.

Stop there and inspect the arguments property.

sapere
25 Feb 2009, 6:31 AM
Interestingly enough, the loadexception event was always firing, and the handler was never given any parameters. I then changed the code to the following:



store.on('blarg', new function(a,b,c) {
alert('fired')
});

Notice the invalid event blarg. This is always being called and the parameters are all undefined. Why?

sapere
25 Feb 2009, 6:45 AM
Alright, nevermind on the event firing issue. My problem was using invalid JavaScript syntax. Instead of using new function(...) {}, I should've of just used function(...){}.

sapere
26 Feb 2009, 7:15 AM
Could be a problem with the content-type being returned by the server for that request?

Getting back to the original point of this thread, I was wondering if you could clarify what was meant by this? Is it possible that the content-type header can cause IE to complain about mixed security? In my case the content-type is application/json.

sapere
26 Feb 2009, 7:52 AM
I'm beginning to think the only logical source of the IE6 security dialog warning of insecure items is the one identified here (http://www.extjs.com/forum/showthread.php?p=233555) (Microsoft identifies this bug here (http://support.microsoft.com/kb/925014/en-us)).

tryanDLS
26 Feb 2009, 9:38 AM
Getting back to the original point of this thread, I was wondering if you could clarify what was meant by this? Is it possible that the content-type header can cause IE to complain about mixed security? In my case the content-type is application/json.
That was a shot in the dark - I would think that application/json should be OK, but I guess you could try forcing it to application/text to see if it makes a difference.

Given that you are working with a complex app, tracking down the icon vs iconCls thing mentioned in that other thread may be an issue. Although given that the bug seems to only occur when something is removed from the DOM, can you narrow it down to something in your app that would be removing a component vs just hiding it?

sapere
26 Feb 2009, 10:00 AM
The UI is constructed with a series of collapsed panels. When a panel is expanded, a GridPanel is rendered to the expanded panel's body. At first I commented out the call to the grid's JsonStore.load(...) method and, when I found this caused the error to stop, I assumed there was something being requested over HTTP.

However, after realizing that loading the store then causes the GridPanel to redraw with the newly retrieved contents, I wondered if the problem may not have been related to the store at all, but the redrawing of the grid. To test this, I explicitly called store.load(...) each time and commented out the call to grid.render(). That is, I confirm in Firebug that another XHR request is being made while the grid is never rendered. The result? The error no longer occurred.

So, what does this mean? The error is undoubtedly coming from rendering the grid and not from loading the store. So there is no HTTP traffic causing the problem, it's the goofy div deletion problem IE has. I haven't found the offending code yet, but it must be there.

tryanDLS
26 Feb 2009, 10:19 AM
So it would be related to repainting the grid, which removes everything and redraws. Are any of your columns images? Or using the red triangle that indicates a modified value? Can't think of anything else in the grid that would be a cause of this.

sapere
26 Feb 2009, 10:34 AM
So it would be related to repainting the grid, which removes everything and redraws. Are any of your columns images? Or using the red triangle that indicates a modified value? Can't think of anything else in the grid that would be a cause of this.

Yes, a few of my columns contained images. But, after removing them from the columns, the problem is still occurring. And I'm not using an editable grid so the red triangle isn't a factor.

Thanks for the input (keep 'em coming if you have any more). I'll keep searching.

sapere
26 Feb 2009, 12:06 PM
I found a solution that works for me.

I was previously rendering my grid before loading the store. This was mostly for aesthetic reasons, as the loadMask would appear and give immediate feedback to the user that the grid was asynchronously loading the data.

By changing the order the methods were called I was able to fix the problem. So to fix this problem in the future, just call store.load() before grid.render(). This falls into line with the assumption that deleting a div was causing the IE bug to appear, which displays the warning about insecure content.

Now I just need to find a way to explicitly render the loadMask (a low-priority issue). Thanks for all the help.

tryanDLS
26 Feb 2009, 12:16 PM
Hmm..that would imply that maybe the loadmask itself is the culprit? Can you replicate this by just put having a simple div do an update with a loadmask?

sapere
26 Feb 2009, 12:23 PM
I'm not sure quite what you're asking for. Can you give a simple example with JavaScript?

tryanDLS
26 Feb 2009, 12:39 PM
Something as simple as

Ext.get('test').load('foo.html');

Where test is an empty div on your page and foo is some html page on your server. This will display a loading mask similar to what the grid does on load.

sapere
26 Feb 2009, 12:39 PM
Hmm..that would imply that maybe the loadmask itself is the culprit? Can you replicate this by just put having a simple div do an update with a loadmask?

Actually playing with a little more, I'm finding that you might be right. Any configuration where I have a loadMask is reliably producing the problem.

sapere
26 Feb 2009, 2:26 PM
This is my own fault. I overrode the .ext-el-mask style to use a PNG with transparency as a background image instead of the default background color with an opacity set to recreate a transparent effect.

I went to the trouble of doing this because the loadMask doesn't actually apply the opacity filter in our application for some reason (I'm guessing because of clashing existing styles). It just seemed easier than debugging css conflicts.

Anyway, because there was a background-image for the loadMask the stupid IE bug was occurring. Problem was solved by undoing that style overriding.