#5091 closed Bug (fixed)
Domain relaxation partially broken in FF
Reported by: | Wiktor Walc | 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 (1)
Change History (8)
comment:1 Changed 15 years ago by
Milestone: | → CKEditor 3.2 |
---|
comment:2 Changed 15 years ago by
Keywords: | Review? added |
---|---|
Owner: | set to Garry Yao |
Status: | new → assigned |
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.
Changed 15 years ago by
Attachment: | 5091.patch added |
---|
comment:3 Changed 15 years ago by
As states above, 5091.patch is assumed to be resolving both the problem in ticket description and the one in my comment.
comment:4 Changed 15 years ago by
Keywords: | Review+ added; Review? removed |
---|
comment:6 Changed 15 years ago by
Cc: | senthil.kumaran@… added |
---|
comment:7 Changed 15 years ago by
Keywords: | Oracle added |
---|
Let's see if we're able to have it done for the 3.2.