Ticket #92 (new defect)

Opened 4 years ago

Last modified 19 months ago

wymeditor fails when javascript is served from a different domain

Reported by: chris_v Owned by: mr_lundis
Priority: minor Milestone: 2.0
Component: editor Version: trunk
Keywords: ajax, eval Cc:

Description (last modified by mr_lundis) (diff)

Currently, WYM editor only works when its javascript files are served from the same domain as the page embedding the <textarea>. However, especially in high-traffic setups and/or to achieve faster page loading, it may be desirable to serve media files from a different server (e.g. page is located at  http://mysite.com, and media files reside on  http://media.mysite.com).

Unfortunately this is not possible with WYMeditor due to the ajax call in jquery.wymeditor.js, Line 1138 (Wymeditor.prototype.load):

if(typeof XhtmlSaxListener != 'function'){

This is the only way to get loaded functions in the global scope until jQuery.globalEval works in safari


+ this._options.xhtmlParser, async:false}).responseText);

In the setup described above, this._options.basePath will be something like ' http://media.mysite.com/...'. Since the Javascript security model assumes the calling script (jquery.wymeditor.js) to be part of "mysite.com" (because it is embedded in a page served from mysite.com), the ajax call will fail.

(Note: the same applies to the ajax call some lines below; Wymeditor.prototype.configureEditorUsingRawCss() ).

This problem could be avoided if -instead of loading static code through ajax calls- other options for loading scripts dynamically would be employed (like dynamically inserting script tags). One would still have to apply domain relaxiation to the iframe's html (wymiframe.html), but at least this would be possible then.

Change History

comment:1 Changed 4 years ago by jf.hovinne

  • Keywords ajax, eval added
  • Priority changed from minor to critical
  • Status changed from new to assigned
  • Milestone set to 0.5

The XHTML and CSS parsers are now embedded in the main JS file. The issue still occur when you use the language option, so my proposal ( see r474 ), is to embed the language file (like before) in the document's head ( see noajax.html ).

Unfortunately, you'll need to init the WYMeditor namespace before loading the language file, as I don't know any reliable cross-browser synchronous global eval, so we can test the existence of the WYMeditor namespace in the language file ( any idea? ).

comment:2 Changed 4 years ago by jf.hovinne

  • Status changed from assigned to closed
  • Resolution set to fixed

No feedback from the reporter, issue fixed, and taken into account (avoid AJAX calls or provide an alternative when possible).

comment:3 Changed 3 years ago by sazwqa

  • Priority changed from critical to minor
  • Status changed from closed to reopened
  • Resolution fixed deleted

I am currently facing the same issue and the instructions provided does not seem to be working. I am using the latest version of WYMeditor (0.5-rc1).

Am initializing the WYM editor using the following:

<link rel="stylesheet" type="text/css" media="screen" href="/wymeditor/wymeditor/skins/default/skin.css" />

<script type="text/javascript" src="/wymeditor/jquery/jquery.js"></script>

<script type="text/javascript"> var WYMeditor = {}; WYMeditor.STRINGS = []; WYMeditor.SKINS = []; </script>

<script type="text/javascript" src="/wymeditor/wymeditor/lang/en.js"></script>

<script type="text/javascript" src="/wymeditor/wymeditor/jquery.wymeditor.js"></script>

<script type="text/javascript">

jQuery(function() {


classesItems: [

{'name': 'date', 'title': 'PARA: Date', 'expr': 'p'}, {'name': 'hidden-note', 'title': 'PARA: Hidden note', 'expr': 'p[@class!="important"]'}


editorStyles: [

{'name': '.hidden-note', 'css': 'color: #999; border: 2px solid #ccc;'}, {'name': '.date', 'css': 'background-color: pink;'}





Let me know if this is the correct way of doing this or am I missing something ? Just to notify the CS and JSS are served from a static cookie less media server for performance.

comment:4 Changed 2 years ago by mr_lundis

  • Description modified (diff)

I tried to serve WYMeditor from a different domain earlier today, without luck. It's when WYMeditor tries to access the iframe document from the outer page things break.

The question is if it's possible to work around this or if the browser policies makes this impossible.

comment:5 Changed 2 years ago by mr_lundis

  • Owner changed from jf.hovinne to mr_lundis
  • Status changed from reopened to new
  • Milestone changed from 0.5 to 0.6

The removal of the iframe in 0.6 will most likely fix this. Until then there's a workaround for this issue posted in the forum:


comment:6 Changed 19 months ago by sanhammer

Note: See TracTickets for help on using tickets.