Ticket #5091 (closed Bug: fixed)
Domain relaxation partially broken in FF
| Reported by: | wwalc | Owned by: | garry.yao |
|---|---|---|---|
| Priority: | Normal | Milestone: | CKEditor 3.2 |
| Component: | General | Version: | 3.1 |
| Keywords: | Oracle, Confirmed Review+ | Cc: | senthil.kumaran@… |
Description
Under some conditions, FF is throwing this error:
Permission denied for <http://dev.ckeditor.local:8080> (document.domain has not been set) to get property Window.document from <http://dev.ckeditor.local:8080> (document.domain=<http://ckeditor.local>).
(confirmed in FF 3.5.7).
It seems that this bug has been introduced when fixing #4514. Reverting [4492] removes that particular error.
Steps to reproduce
- Using release version of CKEditor, open the following URL in FF: http://dev.ckeditor.local:8080/ckeditor/_dev/releaser/release/release/_samples/replacebycode.html (note: there is a port number in the url)
- edit replacebycode.html sample and add there:
<script type="text/javascript"> document.domain = "ckeditor.local"; </script>
after<script type="text/javascript" src="../ckeditor.js"></script>
(make sure you're editing replacebycode.html, it seems that it does not happen in replacebyclass.html) - reload http://dev.ckeditor.local:8080/ckeditor/_dev/releaser/release/release/_samples/replacebycode.html
- result:
Permission denied for <http://dev.ckeditor.local:8080> (document.domain has not been set) to get property Window.document from <http://dev.ckeditor.local:8080> (document.domain=<http://ckeditor.local>).
Attachments
Change History
comment:2 Changed 3 years ago by garry.yao
- Status changed from new to assigned
- Keywords Review? added
- Owner set to garry.yao
First of all I can't reproduce the bug by following the above steps.
While Wiktor's finding here clue me in another TC which breaks the editor easily: load the editor inside a cross-domain frame, see ticket TC for details:
run OR view source.
[4492] has introduced a pretty nasty piece of window.top where all bugs root from, the problem is that we should never assuming a domain friendly environment.
Back to the original purpose of that codes was to make sure the fix also applied in case editor was placed inside a frame. But by further checking it today, I found the B/F cache doesn't even impact the iframe page at all, so we could safely scope #4514 to host page only.
comment:3 Changed 3 years ago by garry.yao
As states above, 5091.patch is assumed to be resolving both the problem in ticket description and the one in my comment.

Let's see if we're able to have it done for the 3.2.