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

ngRoute breaks with file:// protocol in 1.2.0-rc.3 #4680

Closed
szwacz opened this issue Oct 28, 2013 · 9 comments
Closed

ngRoute breaks with file:// protocol in 1.2.0-rc.3 #4680

szwacz opened this issue Oct 28, 2013 · 9 comments

Comments

@szwacz
Copy link

szwacz commented Oct 28, 2013

Hello.

Here is code to reproduce the issue.
Download it, and launch locally index.html. Problem occurs only with file:// protocol.

Symptoms:
On Chrome, Opera and IE the view will not load. No error visible in console.
On Firefox for some reason this problem doesn't occur, everything works as expected.

Angular 1.2.0-rc.2 was free of this issue.

@szwacz
Copy link
Author

szwacz commented Oct 28, 2013

Correction and furher explanation:
I'm using file:/// protocol in node-webkit where ngRoute with angular 1.2.0-rc.2 was working fine. For browsers earlier versions of angular 1.2.0 are also affected by this issue (and I don't know if it even should ever work because of browsers security model).
I hope my post here makes sense.

@symblify
Copy link

I have been able to replicate this using the code that follows, and it would seem that there is a problem with routing or browser location. The code doesn't request the template through http as it is embedded in a script tag, so the file protocol is not the issue.

Saving the code as file-route-bug.html and opening it in IE or Chrome, I can see in the address bar the URL is being rewritten with #/C:/ at the end (C being the drive letter the file is saved to). This causes there to be no matching route, and so the Hello! does not appear. For some reason Firefox just adds #/ and so the route matches and Hello! appears.

Changing snapshot to 1.2.0-rc.3 makes no difference but 1.2.0-rc.2 seems to fix it.

@szwacz AFAIK node-webkit has a different security model so file requests are trusted. There is also an app protocol you could try but I haven't tested it with Angular.

<!DOCTYPE HTML>
<html ng-app="app">
<head>
  <script src="http://code.angularjs.org/snapshot/angular.js"></script>
  <script src="http://code.angularjs.org/snapshot/angular-route.js"></script>
  <script>
    angular.module('app', ['ngRoute'])
      .config(function($routeProvider) {
        $routeProvider.when('/', {
          templateUrl: 'root.html'
        });
      });
  </script>
  <script id="root.html" type="text/ng-template">
    <p>Hello!</p>
  </script>
</head>
<body>
  <ng-view></ng-view>
</body>
</html>

@JonathanDaSilva
Copy link

Hi.
I have a similar issue, the bug appear only on chrome, I haven't any problem with IE (version 10) and firefox (version 25).
Hope I help you.

Regards.

@ChristianWeyer
Copy link

For me, it appears with Chrome on Windows - but not on MacOSX. Especially with with node-webkit.

@nblumhardt
Copy link

Chrome on Windows here too.

@sebastienroul
Copy link
Contributor

In fact it's not really cause of Angular...

Create a small document <html><body></body></html> on your filesystem and open it with Chrome, FF and IE
In the console type the following lines :

   var urlParsingNode = document.createElement("a");
   urlParsingNode.setAttribute('href', '/');
   urlParsingNode.pathname

In chrome result is : "/C:/"
In FF result is "/"
In IE result is ""

FF and IE implementations considere the drive letter as "the host" and remove it from pathname
CHROME implementation let it as part of the pathname

As the routing is done with the pathname.... bug is here :)

Hack is easy to put in the function urlResolve(url) ... but little bit hungly...
protocole.indexOf("file")...

I'm under Windows...

sebastienroul pushed a commit to sebastienroul/angular.js that referenced this issue Nov 10, 2013
@ghost ghost assigned jeffbcross Nov 11, 2013
jeffbcross pushed a commit to jeffbcross/angular.js that referenced this issue Nov 12, 2013
Chrome and other browsers on Windows often
append the drive name to the pathname,
as described in angular#4680. This would cause
the location service to browse to odd
URLs, such as /C:/myfile.html,
when opening apps using file://.

Fixes  angular#4680
@jeffbcross
Copy link
Contributor

@sebastienroul and I have submitted a fix for this, but before merging into master, I'd appreciate if folks could try this build of angular in your apps to make sure it solves the problem for you:
http://ci.angularjs.org/job/angular.js-jeff/82/artifact/build/

@symblify
Copy link

@jeffbcross the build you refer to solves the problem for me for the example I gave in my earlier comment. Thanks go out to you and @sebastienroul.

@jeffbcross
Copy link
Contributor

Merged: a0932ae

Thanks for all the help identifying the problem and helping to fix it!

jeffbcross pushed a commit to jeffbcross/angular.js that referenced this issue Nov 13, 2013
Chrome and other browsers on Windows often
append the drive name to the pathname,
as described in angular#4680. This would cause
the location service to browse to odd
URLs, such as /C:/myfile.html,
when opening apps using file://.

Fixes  angular#4680
jeffbcross added a commit to jeffbcross/angular.js that referenced this issue Nov 13, 2013
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see angular#4680).

However, there could be cases where users intentionally 
have first path segments that end in a colon 
(although this conflicts with section 3.3 of rfc3986).

The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.

Fixes angular#4939
jeffbcross added a commit that referenced this issue Nov 13, 2013
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see #4680).

However, there could be cases where users intentionally 
have first path segments that end in a colon 
(although this conflicts with section 3.3 of rfc3986).

The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.

Fixes #4939
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014
Chrome and other browsers on Windows often
append the drive name to the pathname,
as described in angular#4680. This would cause
the location service to browse to odd
URLs, such as /C:/myfile.html,
when opening apps using file://.

Fixes  angular#4680
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see angular#4680).

However, there could be cases where users intentionally 
have first path segments that end in a colon 
(although this conflicts with section 3.3 of rfc3986).

The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.

Fixes angular#4939
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014
Chrome and other browsers on Windows often
append the drive name to the pathname,
as described in angular#4680. This would cause
the location service to browse to odd
URLs, such as /C:/myfile.html,
when opening apps using file://.

Fixes  angular#4680
jamesdaily pushed a commit to jamesdaily/angular.js that referenced this issue Jan 27, 2014
Prior to this fix, the urlResolve method would automatically
strip the first segment of a path if the segment ends in a colon.
This was to correct undesired behavior in the $location service
using the file protocol on windows in multiple browsers (see angular#4680).

However, there could be cases where users intentionally 
have first path segments that end in a colon 
(although this conflicts with section 3.3 of rfc3986).

The solution to this problem is an extra check to make sure
the first path segment of the input url does not end with a colon,
to make sure we're only removing undesired path segments.

Fixes angular#4939
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.