Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Blocked loading resource from url not allowed. IE11 #3682

Closed
thaoula opened this issue Aug 21, 2013 · 4 comments
Closed

Blocked loading resource from url not allowed. IE11 #3682

thaoula opened this issue Aug 21, 2013 · 4 comments
Assignees

Comments

@thaoula
Copy link

thaoula commented Aug 21, 2013

Hi Guys,

I recently switched my project to use Angular 1.2rc1.

I have several directives that load templates using templateUrl. The directives work fine in Angular 1.15 in both Chrome and IE.

The directives also seem to work in Chrome using 1.2rc1. However, I get the following error when using IE11.

Blocked loading resource from url not allowed by $sceDelegate policy. URL: wizard/views/events.html

App Folder Structure

/index.html (page the has ng-app)
/wizard/wizardApp.js (Angular Module)
/wizard/views (Angular partials and templates
/wizard/directives (Angular directives)

Regards,
Tarek

@luisrudge
Copy link

I have this issue too.
IE11
Angular 1.2rc1

@ghost
Copy link

ghost commented Aug 24, 2013

I have the same issue.
IE11, Angular 1.2rc1

@kollster
Copy link

I have the same problem. It seems that Angular 1.2.0rc1 does not support IE11 - it might even use browser user agent strings instead of feature detection. When using ng-view, partial html files cannot be loaded using relative template urls. I get the following error:
"Error: [$sce:insecurl] Blocked loading resource from url not allowed by $sceDelegate policy. URL: Partials/Task.html"
When I set the user agent string in IE11 to Internet Explorer 10, everything works normally.

@ghost ghost assigned chirayuk Aug 26, 2013
chirayuk added a commit to chirayuk/angular.js that referenced this issue Aug 29, 2013
It's great that IE11 wants to be compatible enough that it doesn't want
to be special cased and treated differently.

However, as long as one has to have a different code path for IE than
for the other supported browsers, we still need to detect and special
case it.  For instance, our URL parsing code still needs the same
workaround the we used for IE10.  We still see the same Access denied /
TypeError exceptions when setting certain values.  FYI, Angular doesn't
generally blindly test for IE – we also check the version number.

Thanks to modern.ie for the free IE11 test VM.

Closes angular#3682
@netpoetica
Copy link
Contributor

For one of my coworkers, we weren't getting any error, IE11 with 1.2.0rc1 would just turn ng-view into a comment and then Angular wouldn't bootstrap. Weird

jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Sep 25, 2013
It's great that IE11 wants to be compatible enough that it doesn't want
to be special cased and treated differently.

However, as long as one has to have a different code path for IE than
for the other supported browsers, we still need to detect and special
case it.  For instance, our URL parsing code still needs the same
workaround the we used for IE10.  We still see the same Access denied /
TypeError exceptions when setting certain values.  FYI, Angular doesn't
generally blindly test for IE – we also check the version number.

Thanks to modern.ie for the free IE11 test VM.

Closes angular#3682
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014
It's great that IE11 wants to be compatible enough that it doesn't want
to be special cased and treated differently.

However, as long as one has to have a different code path for IE than
for the other supported browsers, we still need to detect and special
case it.  For instance, our URL parsing code still needs the same
workaround the we used for IE10.  We still see the same Access denied /
TypeError exceptions when setting certain values.  FYI, Angular doesn't
generally blindly test for IE – we also check the version number.

Thanks to modern.ie for the free IE11 test VM.

Closes angular#3682
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants