Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9 users
Status: Assigned
Owner:
(OOO until 16th)
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
After some update done automatically last week chrome is blocking some Javascript from FCKEDITOR
Reported by heliodia...@gmail.com, Oct 6 2013 Back to list
Version of Google Chrome (Wrench-> About Google Chrome):
Version of MSI (if applicable):
Using group policy settings? Yes/No


The editor used by my website simply stopped working from one day to the other in all my synchronized computers. Other computers still work. This happened last Thursday. 
 
Can you run bisect-builds.py to identify the version where the regression was introduced? Details at http://www.chromium.org/developers/bisect-builds-py
Sorry, I am not a developer. I can only say that I am using version Version
30.0.1599.66 m

Anyway, after more verification I saw that also Internet Explorer 10 is
behaving the same, and only Firefox works as it should, so I assume that
the update was not of Google Chrome, it was something related to Windows
Update that made changes to the Internet Security Policies, upon which
Chrome relies (but Firefox doesn't).
Cc: srsridhar@chromium.org
Labels: Needs-Feedback
Can you please provide us with a sample URL or a specific file to repro this issue.
Comment 4 by Deleted ...@, Oct 8 2013
I am facing same issue. Chrome developers tool is showing following error message

Uncaught SecurityError: Blocked a frame with origin "https://suite.peoplelogic.com.au" from accessing a frame with origin "https://platform.twitter.com". The frame being accessed set "document.domain" to "twitter.com", but the frame requesting access did not. Both must set "document.domain" to the same value to allow access. 

fckeditorcode3_gecko.js:36
You can use the website http://www.bornmobile.co.il . This is the only site
in English I have using the same infrastructure, all the others are in
Hebrew. But the problem appears here as well.

I have created a test user for you.

Username: testuser
Password: testing123

Go into any post in the blog and try to write a comment - the editor is
stuck. Until last week worked perfectly, and it still works perfectly from
Firefox or from non up-to-date computers regarding Windows Update.

I hope it can help. At this moment I am working with Firefox.

Helio
Comment 6 by Deleted ...@, Oct 10 2013
I've got the same problem as you. pls help me!
Labels: -Needs-Feedback M-32 OS-All
Status: Untriaged
@ heliodiamant: Thank you for providign the detailed info.

Able to repro this issue on Windows and Mac as per comment #5. Issue exists from M30 chrome versions to latest canary. This is working fine in M29 29.0.1547.72.

Working on bisect. Will update the info soon.
Comment 8 by saswat@chromium.org, Oct 10 2013
Cc: mkwst@chromium.org
Per Mike's explanation, here is what you may be seeing:

If a script tries to access a frame from a different origin, this is a violation of the same-origin policy and Chrome steps in to prevent it. Previously, the access would silently fail and we would return a NULL. Now, Chrome throws an exception to inform the script of the error. Some scripts may not be prepared to handle this exception. To fix the problem, the scripts should be updated to use a try/catch block and handle a SecurityError exception.
Comment 10 by mkwst@chromium.org, Oct 10 2013
Owner: mkwst@chromium.org
Status: Assigned
The bisect will probably show one of the (many) CLs associated with  http://crbug.com/17325 

In particular, the error from comment #5 is happening because `fckeditorcode_gecko.js` is (inside FCKTools.FixDocumentParentWindow) walking through all the frames in a document, accessing the frame's 'document' attribute, and attempting to set it's 'parentWindow' attribute.

The `A.document` call used to return `null`, and write an error to the console. Now Chrome is matching Firefox, et al. by throwing an exception in these cases. Wrapping that check in a try/catch block will solve the problem.

This isn't currently throwing in Firefox, because it's gated on an "IsSafari" check, which sniffs the useragent for "applewebkit".
This is a big issue for us. We use FCK editor in our hosted CMS platform and it is not easy to go in and fix the issues in the FCK code. I see lots of other people complaining about this as well. Any chance the Chrome can go back to the version 29 behavior? Is there real benefit from this change to other Chrome users?
Reviewing the thread at https://code.google.com/p/chromium/issues/detail?id=17325, it sounds like the intent of this change was to change behavior to conform to the HTML spec and bring it into line with Firefox and Safari.

However, we do not see any problems with Firefox and Safari -- the failure is specific to Chrome.
Comment 13 by Deleted ...@, Oct 11 2013
Thanks guys, I'd got the same problem then i resolved it using comment #10 :)
Thanks. Since this is a pre-developped platform, I don't have much options
to change the code. But I do know where the IsSafari test is done, so maybe
I could neutralize the error in chrome by doing a similar check. Can you
tell me how Chrome identify itself so I could write a check there for
Chrome?

Thanks in advance.
You could write a simple extension that patches the code, injecting a try/catch.
Comment 16 Deleted
Thanks, will test it tonight.
Unfortunately I couldn't get the attachment from this message... it seems
there was nothing attached... can you send it again?
Why was comment number 16 deleted? It was supposed to have a diff file that solves the problem on FCKEditor... can someone re-publish the file?
Either the author of comment #16 deleted it or the spam filter got a bit ahead of itself and removed the comment.
Comment 21 by Deleted ...@, Oct 16 2013
Please help me fix problems on FCKEditor. Chrome killing my project. Now I must recommend my visitors use FireFox or Internet Explore, it's not nice way !
phjnstar: Is #10 a possibility for you? 
#10 would be a possibility for me if I knew how and where to implement the change...
Hi! We fixed it with replacing this bit of code :

FCKTools.FixDocumentParentWindow = function(A){ if (A.document) A.document.parentWindow=A; for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};

with: 

FCKTools.FixDocumentParentWindow = function(A){try{ if (A.document) A.document.parentWindow=A;} catch(e){};for (var i=0;i<A.frames.length;i++) FCKTools.FixDocumentParentWindow(A.frames[i]);};

Hope it works for you too.

~ Dorien
Dorien, in which file? fckeditor.js ?
fckeditorcode_gecko.js 
I have also used this answer on stackoverflow for making FCK editor work again on ie10

http://stackoverflow.com/a/14052761/2889684
Thank you all. Will try ASAP.
Comment 29 Deleted
Dorien,

First of all, thanks for the effort you are putting on this.

What I can tell you at this point:

The update you suggested for IE10 worked perfectly! IE10 is working again with my site. Thank you very much.

However, the fix for chrome did not have any effect on the site. The JS still doesn't work properly. All I see when I try to publish or comment in Chrome is the editor with a limited toolbar (smaller - in available buttons - than the one I have in the other browsers) and I am not able to write anything in the text box. 

Actually, the same situation I had before. Nothing changed. I hope you can suggest something else...
Comment 31 by Deleted ...@, Oct 30 2013
This change broke use of Chrome with PeopleSoft 8.49. Ironically, it's breaking in a javascript call isCrossDomain(). I had to switch to Firefox which does not have a problem with this same code. Reading through the thread mentioned in #c12 I'm not sure how the change mentioned there was supposed to make Chrome act like Gecko in this situation.
Re #31: Many pages look at the user agent, serving different JavaScript code to Firefox and Chrome. It is possible that PeopleSoft serves code which expects Gecko behavior when the user agent is Firefox and Chrome's old behavior when the user agent is Chrome. This would explain why it breaks when Chrome's behavior becomes more like Gecko.
Comment 33 by kareng@google.com, Nov 8 2013
Labels: -M-32 M-33 MovedFrom-32
Moving all non essential bugs to the next Milestone.
Project Member Comment 34 by bugdroid1@chromium.org, Dec 17 2013
Labels: -M-33 MovedFrom-33
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Is there any update on this issue? We continue to have issue with our PeopleSoft environment and Chrome
Sign in to add a comment