Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#10318 closed defect (worksforme)

dijit.Editor breaks when using HTTPS in IE (suggested fix inside)

Reported by: Phil DeJarnett Owned by:
Priority: high Milestone: tbd
Component: Editor Version: 1.3.2
Keywords: Cc:
Blocked By: Blocking:

Description

If you have a dijitEditor on an HTTPS host, IE will load an error page in the iframe, and the Editor will not work at all.

There is an easy solution, according to here: http://www.aqris.com/display/DEV/2006/12/01/KNOW-HOW+-+iframes+and+https+under+IE

The simple solution: set the initial src to "javascript: false;", then change the source to your custom content later. You already have the delay in place, just remove the Safari check, and replace the first setAttribute with the above code.

This seems to work perfectly in IE7 and IE8. It also did not appear to have a negative effect on Chrome or Safari, either in performance or in bugs. However, it did break on Opera. The solution here is to use the old method for Opera. Obviously you could still use the old method for Safari/Chrome?, but this seems like the least amount of code changes.

Final replacement code block:

ifr.setAttribute('src', dojo.isOpera ? s : 'javascript: false;');
this.editingArea.appendChild(ifr);
if(!dojo.isOpera){ // Fix for iframe content
    setTimeout(function(){ifr.setAttribute('src', s)},0);
}

Note: I do not have a CLA filed, and I don't have the ability to write test cases at this time. I have patched the fixed on my local copy using the above instructions. Also, it is only reproducible on an SSL secured website, so it may be difficult to test.

Change History (8)

comment:1 Changed 10 years ago by bill

Component: DijitEditor

FYI, we've been around and around on the https security warnings, see for example #548 and #427. Various incantations were javascript:void(0), javascript:"", about:blank, a real blank.html, etc.

Another option is to inline the boilerplate text, like javascript:"<html><body>...." rather than the current parent reference javascript:parent.dojo.byId("'myId'")._iframeSrc. There was code to do that before for FF2, see http://bugs.dojotoolkit.org/changeset/20190#file17 (but the replace() syntax is non-portable, should be replace(/'/g, "
'") IIRC).

This is failing for you in 1.3?? Not the 1.4 beta?

comment:2 Changed 10 years ago by bill

I tried it test_Editor.html over https:// on both 1.3 and 1.4 on IE8 and IE6. All working fine for me.

Not sure what to say, I occasionally see reports about https:// not working that I can't reproduce.

I installed SSL into apache following the instructions in http://developer.apple.com/internet/serverside/modssl.html.

comment:3 Changed 10 years ago by Phil DeJarnett

Well, if it helps any, this is a commercial (wildcard) cert, not a self-signed cert. Maybe IE treats self-signed differently than commercial ones?

Also, the Editor is being created dynamically, after the page is loaded completely. (My app is a long-running web app, and doesn't reload the main page as long as the user is logged in.)

At any rate, I *could not* get Editor to work in IE 8 or 7 without the change I mentioned, and it works perfectly *with* the change I recommended.

Also, FWIW, it is not a JS error being thrown (nothing about mixed content). I realize now I wasn't clear on this. IE just replaces the iframe content with a message saying something like "The load was canceled". I can't remember the exact phrasing.

comment:4 Changed 10 years ago by Jared Jurkiewicz

Can you sign a CLA? We can't accept code submissions without one on file.

comment:5 Changed 10 years ago by Phil DeJarnett

Just an update: My "fix" won't work, because IE apparently clobbers the browser's history when you set the src of the iframe (probably only after it has been added to the dom tree).

I'm really banging my head against the wall, now. I read somewhere that Dojo 1.4 might already have a fix in the works, but it might need to be tested against the new onHashChange handler to see if IE8 still clobbers the history when it is loaded.

I still don't have a solution, and breaking the history breaks other features on my page.

comment:6 Changed 10 years ago by Phil DeJarnett

Well, this is the very definition of hack. You might as well close this bug, because this is how I ended up resolving it:

  • For all browsers except IE: use the original methods (set it, set it again in webkit browsers)
  • For IE,
    1. Don't set the src on the iframe at all.
    2. Upload to the server (via a synced xhrPost) a copy of this._iframeSrc (stored in a session variable)
    3. After that is done, set ifr.src to a special URL that kicks back the just-uploaded content.
    4. Continue on.

However, as hacky as it feels, it works very well. The history is not clobbered, and there are no SSL issues. I'm sure the speed might be an issue, but with how slow everything is in IE to begin with, it might not be that noticeable.

Hopefully when Dojo 1.4 is released (and I have time to integrate it), I can go back to using Editor without these hacks. :-/

comment:7 Changed 10 years ago by bill

Resolution: worksforme
Status: newclosed

OK, I'll close it for now, hopefully 1.4 will fix the problem.

comment:8 Changed 10 years ago by Jared Jurkiewicz

There was a fix put into the 1.3 branch (post 1.3.2) that resolved a secure/insecure issue with IE 7.

http://bugs.dojotoolkit.org/ticket/9731

There's a patch + UT fix for it.

I recommend applying it to your 1.3.2 and see if it resolves your issue. The same fix is already in 1.4.

Note: See TracTickets for help on using tickets.