PDA

View Full Version : [OPEN-1376] Insecure warning in IE on component destroy



tigran
2 Nov 2010, 8:49 AM
Guys how to generate minified ext-all.js and ext-base.js from their debug versions?

Also a question. Is there a single place EXT using removeChild method of the dom. There is such an issue with IE working with HTTPS. So when you calling removeChild for an element which contains background-image style declared, IE brings you 'Security Message' about mixed content. Is it possible to fix it from single place? I think this some sort of common issue. Basically the component destroy causing this issue. Here are reports of the Microsoft about it:
http://support.microsoft.com/kb/925014

Thanks

jsakalos
2 Nov 2010, 10:11 AM
These are part of the download package so you already have them. Anyway, you can use yui-compressor (http://developer.yahoo.com/yui/compressor/) or jsmin (http://www.crockford.com/javascript/jsmin.html) or combination of both.

tigran
2 Nov 2010, 10:20 AM
Which one is used for the download package? Anything about the second question?

jsakalos
2 Nov 2010, 10:37 AM
Both ext-all.js and ext-base.js are included in ExtJS download package (http://www.sencha.com/products/js/thank-you.php?dl=extjs330).

About insecure warning: Is your Ext.SSL_SECURE_URL (http://dev.sencha.com/deploy/dev/docs/?class=Ext&member=SSL_SECURE_URL) correct?

tigran
2 Nov 2010, 10:43 AM
I know that minified versions are included. I am just asking in case if I need to modify something in debug version how to generate pretty much the same files.
Actually Ext.SSL_SECURE_URL used for the Iframes. The problem with dom removeChild is different one. I anyway specified Ext.SSL_SECURE_URL in my code. But I go through debug version of ext and find out that the problem of IE it gives on component destroy is where it finally using removeChild method. This is really not an Ext bug, but IE issue. The problem is that I need to modify an ext code to prevent that stupid issue. Checkout the link I mentioned in first post.

Thanks

jsakalos
2 Nov 2010, 11:09 AM
1. I would never edit library files and then repack them. It is always better, for many reasons, to use Ext.override (http://dev.sencha.com/deploy/dev/docs/?class=Ext&member=override) and keep ExtJS files untouched.

2. It is possible that Ext needs a workaround of that IE bug, nevertheless, the article you posted the link to states that if background is set in css class then removing an element doesn't trigger the error. Can you confirm this?

tigran
2 Nov 2010, 11:18 AM
Yes, basically that is what they are saying. The problem that I am getting that Alert when calling removeAll method of the Ext.Panel, which seems don't have anything to do with my code. I was thinking if Ext code will assign background-image style to some element inside the Panel, then it seems to be possible to get that issue

jsakalos
2 Nov 2010, 12:12 PM
Yes, it can be. If you'd prepare a showcase, I could move this thread to Bugs for the devel team to comment/fix it.

tigran
3 Nov 2010, 2:41 AM
It seems that I fixed an issue, by modifying ext code. I is really tricky to prepare a show case, but I modified all removeChild calls with this function

function removeFromDom(el, elParent) {
if (el != null) {
var p = (elParent != null ? elParent : el.parentNode);
var isIE = /msie/.test(navigator.userAgent.toLowerCase());
if (isIE) {
if (el.tagName == 'TD') {
p.deleteCell(el);
} else if (el.tagName == 'TR') {
p.deleteRow(el);
} else {
el.outerHTML = '';
}
} else {
p.removeChild(el);
}
}
}

Again this is not an Ext issue, and I am pretty sure that many users who getting that 'Security Alert' will not even assume that removeChild can be a reson for it. From that standpoint there is no way to extend all that stuff from Ext, and the only way to do that is to modify original files. So I would like to see that logic fixed inside. Please pass to dev team if possible, I think it will be usefull, since it's was really hard to determine that removeChild causing a problem, and again many people will not even assume that it might be a reson of that issue. Verified on IE8, 7.

jsakalos
3 Nov 2010, 3:43 AM
In any case, I think that it is good if the devel team knows about it so I'm moving this thread to bugs.

jsakalos
3 Nov 2010, 3:44 AM
Note: I've changed the title to be more descriptive.

Condor
3 Nov 2010, 4:08 AM
Ext has it's own logic to remove a child.

On IE6 and 7 it moves the node to a temporary div and it clears the innerHTML.
On all other browsers (including IE8) it just calls removeChild.

It that the code that is failing?

tigran
4 Nov 2010, 1:20 AM
Basically no. I modified that part also. But there are removeChild calls from inside ext-all as well. Basically main problem is removeChild method. But cleanup logic you wrote for IE7 ans IE6 were failing as well. The point here is that problem goes away when you are using outerHTML for IE to remove an elements which contains background-image style (or even any child of that element had it).

lechenique
8 Dec 2010, 5:05 PM
Hi,
I just wanted to know where can I keep track of the progress of this issue.

I have good reasons to believe that we are experimenting the same type of issue in our Portal. Recently we move the portal to SSL/https and these apparently random IE messages warning about mixed content started to show up.

We encountered the same issue with a GIS javascript library that we use; after applying a patch that they provided, dealing exactly with this removeChild, the warnings mostly stopped.

But we are still getting sporadic warnings and I started wondering if ExtJS might have the source of them. We are currently using ExtJS 3.2

I would appreciate any updates or further information about it.

Thanks.

mdm-adph
23 Dec 2010, 7:51 AM
I've been getting this same message for years now -- setting Ext.SSL_SECURE_URL makes no difference. I've set it to gifs and to empty files. It doesn't matter what the user clicks, either yes or no -- I've about given up.

meroy
29 Dec 2010, 12:14 PM
An email was sent to the dev team to let them know this is still an issue.

mdm-adph
30 Dec 2010, 6:24 AM
I wonder what's the deal, though -- is there a really simple solution to this problem that people just come across, and then forget to write about, or is not much development done with ExtJS via https (I _know_ this cannot be it)?

Piruthu
14 Mar 2011, 1:13 AM
I wonder what's the deal, though -- is there a really simple solution to this problem that people just come across, and then forget to write about, or is not much development done with ExtJS via https (I _know_ this cannot be it)?

+1

amal.arindam
31 Mar 2011, 2:13 PM
Hi,
It would be really helpful if somebody can give a temporary solution. If EXT JS files are not fixed, then at least for now, we would need to fix it on our end. The user "tigran" did provide a solution to handle it. But i am just wondering where to plug it in the source file. Please help me in getting this fixed. This is really critical for me.

SAP
19 Apr 2011, 10:49 PM
Hi Condor,

I am facing sililar issue but randomly.

I have seen traffic using HttpWatch.

Everything except "Ext.chart.Chart.CHART_URL=http://yui.yahooapis.com/2.8.2/build/charts/assets/charts.swf" is using HTTPS secure connection in my application.

Can it be the reason for warning pop ups?

If yes, what can be the possible solution to avoid it?

Thanks & Regards,
Anand

SAP
19 Apr 2011, 10:53 PM
Hi,

I have seen traffic using HttpWatch.

Everything except "Ext.chart.Chart.CHART_URL=http://yui.yahooapis.com/2.8.2/build/charts/assets/charts.swf" is using HTTPS secure connection in my application.

Can it be the possible reason for warning pop ups?

25735If yes, what can be the possible solution to avoid it?

Thanks & Regards,
Anand

jsakalos
20 Apr 2011, 10:32 AM
You could download charts.swf to your server and serve it from over https protocol (if it does not violate possible licenses). BTW, charts.swf is in Ext 3.3.3 download package. If it is same then you just need to set Ext.chart.Chart.CHART_URL to your server (https://.....)

Piruthu
24 Apr 2011, 10:03 PM
Hi,
It would be really helpful if somebody can give a temporary solution. If EXT JS files are not fixed, then at least for now, we would need to fix it on our end. The user "tigran" did provide a solution to handle it. But i am just wondering where to plug it in the source file. Please help me in getting this fixed. This is really critical for me.

While destroying a panel, instead of directly calling destroy() you could try


var isIE = /msie/.test(navigator.userAgent.toLowerCase());
if(isIE){
if(Ext.getCmp(yourPanelId)&& Ext.getCmp(yourPanelId).getEl() ){
Ext.getCmp(yourPanelId).getEl().dom.outerHTML='';
}
}
else {
if(Ext.getCmp(yourPanelId)){
Ext.getCmp(yourPanelId).destroy();
}
}