You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
Force refreshing on a route causes $location.path() to be wrong. #2762
When I navigate to a route such as http://www.test.com/products/management and force a refresh, the $routeProvider fails to match it against any routes and pushes me back to http://www.test.com/products (not even a valid route!). I think that this is because $location.path() incorrectly reports the current path as /management.
Here's my route configuration for reference:
angular.module('labelLogicLiveApp').config(function($locationProvider,$routeProvider){// Use HTML5 strategy if available.$locationProvider.html5Mode(true).hashPrefix('!');$routeProvider.when('/',{templateUrl: '/views/home.html'}).when('/user/login',{templateUrl: '/views/user_login.html'}).when('/product/management',{templateUrl: '/views/product_management.html',resolve: {isAuth: 'authService'}}).when('/product/:productId',{templateUrl: '/views/product_details.html',resolve: {isAuth: 'authService'}}).otherwise({redirectTo: '/'});});
I see this too. Looks like a regression introduced in 1.1.5, as it was working fine in 1.1.4. The only precondition to trigger this is to load the url without #/, no force refresh needed.
Seeing the same thing and can corroborate the part where it was working in 1.1.4
I have a few routes in my app with varying lengths and the behavior I'm seeing is that the last slash and stuff behind it is gone. So a route like /display/foo/123 becomes /display/foo and something like /create/foo becomes /create
Ah, and there was me thinking it could just be me being silly! lol. I'm going to test in 1.1.4 to double check that this has been introduced in 1.1.5 and report back.
Adding a element is not a good solution. It changes the way the browser handles relative paths and breaks many third-party libraries/widgets, especially those that use urls in SVG like some color pickers.
What @clkao mentioned is not a workaround, but a requirement for the router to work properly. if you don't set base[href] then we have no way of telling what is the root path of your app and all of the links and static resources in your app will be loaded from the wrong location (unless you use absolute paths).
@IgorMinar I wasn't until @clkao pointed it out, but now I am. Perhaps this needs to be made a bit clearer somewhere in the documentation... Plus I'd put the tag into the Yeoman generator-angular project with a dummy value, as that'll force people to notice!
Activity
thatmarvin commentedon May 23, 2013
I see this too. Looks like a regression introduced in 1.1.5, as it was working fine in 1.1.4. The only precondition to trigger this is to load the url without
#/, no force refresh needed.kapusta commentedon May 24, 2013
Seeing the same thing and can corroborate the part where it was working in 1.1.4
I have a few routes in my app with varying lengths and the behavior I'm seeing is that the last slash and stuff behind it is gone. So a route like /display/foo/123 becomes /display/foo and something like /create/foo becomes /create
Siyfion commentedon May 24, 2013
Ah, and there was me thinking it could just be me being silly! lol. I'm going to test in 1.1.4 to double check that this has been introduced in 1.1.5 and report back.
Siyfion commentedon May 24, 2013
I can confirm that this bug was definitely introduced in v1.1.5; v1.1.4 works fine.
geddski commentedon May 24, 2013
Duplicate of #2774
I ran a git bisect and found it was commit 58ef323
ilplotkin commentedon May 24, 2013
$location.path()onhttp://server/path/file.htmlreturnsfile.htmlin 1.1.5 (it returned empty string in 1.1.4).Looks like that it's related issue.
petebacondarwin commentedon May 24, 2013
Actually #2774 is a duplicate of this one!
Siyfion commentedon May 24, 2013
I was just about to say... You can't close them both! 😄
petebacondarwin commentedon May 24, 2013
I think the issue is here https://github.com/angular/angular.js/blob/master/src/ng/location.js#L504
clkao commentedon May 28, 2013
You can workaround the issue in 1.1.5 by adding
<base href="/">, as mentioned in #2799 (comment)geddski commentedon Jun 11, 2013
Adding a element is not a good solution. It changes the way the browser handles relative paths and breaks many third-party libraries/widgets, especially those that use urls in SVG like some color pickers.
IgorMinar commentedon Jun 11, 2013
Are you guys setting
base[href]in your apps?What @clkao mentioned is not a workaround, but a requirement for the router to work properly. if you don't set
base[href]then we have no way of telling what is the root path of your app and all of the links and static resources in your app will be loaded from the wrong location (unless you use absolute paths).Siyfion commentedon Jun 12, 2013
@IgorMinar I wasn't until @clkao pointed it out, but now I am. Perhaps this needs to be made a bit clearer somewhere in the documentation... Plus I'd put the tag into the Yeoman generator-angular project with a dummy value, as that'll force people to notice!
fix($location): default to / for the url base if no base[href]
IgorMinar commentedon Jun 14, 2013
so it turns out that base[href] approach has some issues. see the commit message of 2bc62ce for more info.
geddski commentedon Jun 14, 2013
Here's an idea that would help: #2805