Thread

Hi Ben,

I let the team know. Keeping this open a bit longer to track.

Cheers,

any update on this? it is already causing mischief http://devot-ee.com/add-ons/support/firemail/viewreply/15503

(As mentioned, i made a simple php-script with a form and jquery on my local machine, but i couldn’t replicate this error).

However i did find a work-around:
For me, the problem went away when i remove the GET variable ?v=xxx from the jquery url.
Chrome now doesn’t throw the error anymore.
In the file: /system/expressionengine/libraries/View.php line 90, Method: public function script_tag($file)

//$url = $this->EE->config->item('theme_folder_url') . 'javascript/' . $src_dir . $file . '?v=' . $filemtime;
  $url = $this->EE->config->item('theme_folder_url') . 'javascript/' . $src_dir . $file;

Hello Ben,

I do not have any updates at this point in time.

Is this still an issue? I noticed that Chrome has released version 17.0.963.56.

Cheers,

Hey guys,

I’m not able to reproduce this either, though I don’t use Chrome as my primary browser. I’m using Chrome 17 with relatively few extensions. If you try this in in Incognito mode (effectively disabling extensions), do you still have the problem? If not, I would hunt down the particular extension that’s causing the problem.

Report back what you find. To be honest, if folks who aren’t running EE are also having this issue when trying to submit anything with

src="*"

in it, the problem’s more likely an issue with Chrome or an extension.

yes, still happens in latest version of Chrome and in Incognito mode. in summary:

- the underlying issue is a Chrome issue: “Refused to execute a JavaScript script. Source code of script found within request.”

- the issue can be replicated by publishing an entry in Chrome and inserting an image tag into a textarea with a full url that is on the same domain.

- the issue seems to be resolvable when the GET variable ?v=xxx is removed from loaded scripts such as jquery.

clients of mine are starting to report this and i am telling them to use Firefox to avoid it, so i would call this an urgent issue.

thanks kevin!

Hi Ben,

I completely understand the urgency, but I’m still not able to reproduce this on my end following the exact steps you’ve laid out above. My thinking is that it’s caused by Chrome in combination with some Fieldtype, Accessory, or Extension that’s not part of the native install. What are the Fieldtypes in use on your publish page (first- and third-party)? Are you using any Accessories or Extensions?

Kevin, i don’t know if you’ve read all comments but here is a screencast of the issue,
showing step by step how the issue happens on a fresh virgin install of 2.4 (Chrome, Mac)

http://www.screenr.com/Pqys

edit: Kevin, not src=”*” but from the same domain src=“http://example.com”

Thanks for the clarification, GDmac. I likely was getting the error before but just wasn’t looking in the right spot for it.

Now that I can see it, though—and please forgive the bluntness—I’m still not exactly sure why it’s being reported here. From the bug report Ben linked above, this appears to be an issue that will have to be resolved in Chrome since it doesn’t present itself in other browsers (including older versions of Chrome), appears to be a bug rather than an intentional security feature in Chrome, and isn’t exclusive to EE.

In short, it’s a bug in the browser. I know it’s not the answer you’re looking for, but your clients may need to use another browser until Chrome is fixed.

Kevin, i acknowledge that it this “also” “probably” is a browser bug.
If you look at the very first post i submitted, i asked:

- It would be really helpful if there would be a way around it.
- I guess this might need altering the preview entry page.

Since i couldn’t replicate it locally with a hacked together PHP form with JQuery et all etc,
i suspect it is a bit more elaborate to debug and has to do with various parts of the form/return setup.

Also i’m hoping you (EllisLab) are in a position to elevate this a bit on the other side (Chrome).
I contacted Paul Irish about this, but this requires a testcase for chrome devs to able to look at.
https://twitter.com/#!/paul_irish/status/169115683475570688

yes, understand that it is a chrome bug (webkit to be more exact), like GDmac was looking for feedback and a proactive response from EllisLab. it looks like this bug has been fixed, although i’m not sure how long it’ll take until it enters the next stable release of chrome.

thanks for looking into it kevin!

GDmac - We’re not really in a position to influence development of Chrome any more than you are, I’m afraid. Thanks for bringing this to our attention though.

Glad I could help confirm it, Ben. Like you said, it looks like it’s been fixed in WebKit, so now it’s just a matter of it making its way into Chrome.

I’ll consider this resolved since it looks like it’s all in the hands of the Chrome development team to implement the fix. Thanks guys!