Opened 12 years ago
Closed 12 years ago
#8373 closed defect (invalid)
Secure & unsecure message in IE
Reported by: | lahiri | Owned by: | anonymous |
---|---|---|---|
Priority: | high | Milestone: | tbd |
Component: | General | Version: | 1.1.1 |
Keywords: | dojo | Cc: | alex, psowden |
Blocked By: | Blocking: |
Description
This page contains bothe Secure and Non secure items"message in IE. When I commented the following piece of code from dojo.js.uncompressed.js file, the message is gone.
if(dojo.isIE){ if(!dojo.config.afterOnLoad){ document.write('<scr'+'ipt defer src="//:" ' + 'onreadystatechange="if(this.readyState==\'complete\'){' + dojo._scopeName + '._loadInit();}">' + '</scr'+'ipt>' ); }
Attachments (2)
Change History (19)
Changed 12 years ago by
Attachment: | dojo.js.uncompressed.rar added |
---|
comment:1 Changed 12 years ago by
comment:2 follow-up: 15 Changed 12 years ago by
There have been other changes regarding javascript: urls too, I believe. Have you tried testing with the latest version of Dojo or at least 1.2.3?
comment:3 Changed 12 years ago by
FYI the dijit issues IIRC were all about specifying a dummy URL for an <iframe> or <img>. Doing:
- not defining a src/href
- using javascript:void(0)
- using blank
etc. all caused intermittent problems so we ended up with referencing a blank.html or blank.gif file.
But I think that's unrelated to this problem.
comment:4 Changed 12 years ago by
FWIW, this is the changeset. It's old. Does anyone know what the ":" is all about?
comment:5 Changed 12 years ago by
Cc: | alex psowden added |
---|
comment:7 Changed 12 years ago by
And I wonder if its even needed? src= is optional on script. So could that be completely removed and the behavior kept the same?
comment:8 Changed 12 years ago by
Other related tickets to that weird looking: ":"
http://bugs.dojotoolkit.org/ticket/3139 http://bugs.dojotoolkit.org/ticket/3519
comment:10 Changed 12 years ago by
comment:11 Changed 12 years ago by
Just talked to peller offline: here is my understanding: the ":" was seen as https-safe, and we needed a defered script to simulate the "DOMContentLoaded" event for IE.
AFAIK, this has been working fine for a while, it would be good to confirm with the original reporter that loading only dojo.js (not dojo.requiring anything else, and not having any other dojo modules in dojo.js than the standard Dojo base) works OK in their https situation. Or if one of use can repro on an https URL with plain Dojo Base, that would be a cause to re-evaluate.
comment:12 Changed 12 years ago by
I don't think the noted code is the problem. By commenting it out, all that effectively does is disable dojo from finishing initialization. So, if dojo doesn't init, no widgets get parsed and little gets instantiated.
I set up an SSL environment using IHS an dojo 1.1.1 and I do not hit any secure/insecure errors from IE when it loads various dijit tests.
I even loaded things like themeTester, which loads just about every dijit in existance and then some, and uses them in various ways. No secure/insecure errors.
So ... this currently leads me to think the user may have custom widgets or are using a widget incorrectly to cause that problem to occur. We need more narrowing information from the user, such as what widgets do they use, if they have any custom widgets, and if they can provide a simplified testcase.
I re-iterate here that as far as I can determine, the noted line is not the problem. Commenting it out simply disables dojo's init, so any widgets, etc, never fully parse and set up, and therefore any problems in them do not reveal themselves.
The defect originator needs to update this defect with more information as to what their app is doing with dojo and what widgets it uses.
comment:13 follow-up: 16 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
jaredj: Thanks for doing this test. I am going to close this bug for now, but the original submitter can reopen with more information.
comment:15 Changed 12 years ago by
Replying to peller:
There have been other changes regarding javascript: urls too, I believe. Have you tried testing with the latest version of Dojo or at least 1.2.3?
We are using the dojo that came with Portal Server 6.1 which is version 1.1.1
comment:16 Changed 12 years ago by
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Replying to jburke:
jaredj: Thanks for doing this test. I am going to close this bug for now, but the original submitter can reopen with more information.
Please find the attached screenshot which contains the URL which IE terms as an error url-http://:/ I removed the src=":" from dojo.js attribute and that Error URL is gone. Just for testing purpose I updated the dojo version to 1.3 from 1.1.1 which is shipped with Websphere Portal Server 6.1
comment:17 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | reopened → closed |
lahiri: it looks from that screenshot that you are using HTTPWatch to watch the network traffic. That particular tool seems to catch network requests before they leave the browser, and what you are seeing is a lower level error report. However that error report is not bubbled up to the JavaScript? layer, so it should not be the source of the problem.
As Jared mentioned in a previous comment, by removing that src=":", you are effectively stopping dojo from initializing correctly, and the error is probably related to something that initializes as part of the dojo initialization step, probably as part of a dojo.addOnLoad callback. So it does not really solve the problem, and you are likely to hit subtle issues because dojo is not fully initialized.
The best thing to do is to isolate code that calls dojo.addOnLoad() to see which initialization block might be the source of the real error. I would start with the non-dojo/dijit/dojox addOnLoad calls first. Note that Jared tried a similar test over SSL without removing the src=":" line and all of the dijit tests he tried worked. Feel free to reopen this ticket and post more info if you isolate the dojo.addOnLoad call that might trigger the error.
I am surprised this makes a difference: there have been reports of the secure/unsecure message in IE, but I believe it is has been a result of specific modules doing something to cause the error. From what I can recall, there were some things with some uses of some dijits that caused the issue?
If you remove all dojo.require calls and load dojo.js by itself, I believe that works on https connection, so I do not think this change makes a difference: it probably causes a side effect where maybe one of the dojo.required modules does not load perhaps?
But if you can confirm, loading plain dojo.js with the above line activated, I would expect that to work.