This bug concerns Whizzywig versions below 60 in Chrome and perhaps other Webkit based browsers.
Whizzywig versions below 60 use document.write()
calls to insert its code into the DOM tree. As this does not work well together with Wysiwyg we override their shorthand function (w()
) in whizzywig.js and whizzywig-56.js. Our function buffers the output until just before Whizzywig tries to access its iFrame, at which point we insert the buffered contents into the DOM. We do this by overloading Whizzywig's shorthand for document.getElementById()
(o()
) as well and checking for when the iFrame's id is requested.
The iFrame (and other content along with it) is inserted using jQuery.after()
into a wrapper div so we can easily remove it later. For some reason, the iFrame's .contentWindow
property becomes null when inserted this way. As Whizzywig tries to access the iframe.contentWindow.document
shortly after, the aforementioned error is thrown. The editing area itself also becomes non-responsive as it is empty.
Just inserting our div wrapper via jQuery.after()
and then inserting the iFrame and related contents into it using jQuery.html()
afterwards seems to work fine though.
Comment | File | Size | Author |
---|---|---|---|
#1 | wysiwyg-whizzywig-922436.patch | 2.43 KB | TwoD |
Comments
Comment #1
TwoDAnd here's a simple patch...
Note that Whizzywig versions 60+ will still have other issues, this is just for versions below 60.
Should apply cleanly to all -dev versions, just a couple of offsets.
Comment #2
TwoDInterest in this editor seems low. :/ Oh well... RTBMe, I can't properly use the editor without the patch and this workaround is simple enough.
Comment #3
sunThanks for reporting, reviewing, and testing! Committed to all branches.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.