Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

$urlRouterProvider's when function has redirection problems #2496

Closed
nmrm opened this issue Jan 28, 2016 · 3 comments
Closed

$urlRouterProvider's when function has redirection problems #2496

nmrm opened this issue Jan 28, 2016 · 3 comments
Labels
Milestone

Comments

@nmrm
Copy link

nmrm commented Jan 28, 2016

$urlRouterProvider has a problem if the incoming path that I want to redirect is empty and there is a state with an url that is also empty.

If I declare something like:

    $urlRouterProvider
        .when('','/staff')
        .otherwise("/error");

and then I declare a named state with an empty "url"...

When calling the webapp in it's root format, http://host:port/webapp

  1. Chrome, ignores the $urlRouterProvider and jumps into the state with the empty url (bug).
  2. IE and Firefox works fine following the rule in the $urlRouterProvider, jumping into the state that has the '/staff' associated url.

The 1) glitch started happening since lib version 0.2.16 and only in Chrome browsers.

@Spessi
Copy link

Spessi commented Jan 29, 2016

Hi, I'm facing the same problem with Chrome. Plunkr here: https://plnkr.co/edit/FrDapa80tndHvyGW6ckt (minimalistic example)

I've set
$urlRouterProvider.when('/main2', '/main2/sub1/subsub1');
$urlRouterProvider.when('/main3', '/main3/sub1/subsub1');.
So clicking on the link "Main 2", it should open automatically its subsub1 view. The same with "Main 3".

When I use version 0.2.16 and 0.2.17 of ui-router it's not redirecting to /main2/sub1/subsub1" in Chrome, but in Firefox and Internet Explorer it does. The automatically redirection to "/main3/sub1/subsub1" works in all three browsers. With ui-router 0.2.15 everything works as expected.

@christopherthielen
Copy link
Contributor

We suspect this may be related to merging in #1585 and the sort order of routes changing. We plan to revert #1585 and targeting this to be back to normal in 0.2.18.

Sorry for the troubles.

@christopherthielen christopherthielen added this to the 0.2.18 milestone Jan 29, 2016
@cdriscol
Copy link

@christopherthielen, @Spessi, @nmrm: I submitted a PR that likely will fix your issue with Chrome.. #2502

Basically it just ensures a stable sort on Chrome for the sorting that got added in #1585.

I'm also open for reverting the PR that added the sort - but we may be able to keep that sort and not have Chrome issues with my PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants