FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

$location.search() returns undefined when base href does not match URL · Issue #16241 · angular/angular.js · GitHub

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.

$location.search() returns undefined when base href does not match URL #16241

Description

I'm submitting a ...

  • bug report

Current behavior:

In our app's run function, $location.search() returns undefined.

Expected / new behavior:
$location.search() should return an object, as documented.

Minimal reproduction of the problem with instructions:

Serve page at https://localhost/foo/bar/

include tag <base href="/baz/">

Use HTML5 location mode.

see http://plnkr.co/edit/RRJMNjo6Viw1NbtNeWfr?p=preview

AngularJS version: 1.5.10

Browser: Chrome 61 | Firefox 57

Anything else:

Oh, this may be a duplicate of #11223. That issue got sidetracked to a discussion of case-sensitivity and then marked as wontfix, but I think that was a tangent unrelated to making search() return properly.

In a way much like #14488 noted for $location.$$absUrl, the $location.$$search property may not be initialized before $location.search() is called.

Perhaps the search() method needs to check to see if $$search is undefined, similar to how other functions check for a value for $$path or $$hash, or perhaps when $locationProvider.$get needs to always call $location.$$parse (which $location.$$parseLinkUrl declines to do in this condition).

I also noticed that sometime later $location.search() would return properly; I suspect this is related to how $locationProvider.$get adds a watch to $rootScope, but the app's run function probably happens before that digest cycle.

Activity

  1. gkalpak commented on Sep 25, 2017

    Member

    As noted in the docs, $location will indeed not work correctly in this case:

    The $location service is not able to function properly if the current URL is outside the URL given as the base href.

    We could make $location use a different baseHref, but link-rewriting would be broken.

    TBH, I am not even sure what the usecase is. Why load AngularJS on a page that doesn't match the intended baseHref?)

  2. added this to the Purgatory milestone on Sep 25, 2017
  3. keturn commented on Sep 25, 2017

    Author

    The canonical location is /baz/, and any links that people copy should use that location, but sometimes it's served at other locations. Either as an alias for compatibility reasons, or it's an endpoint that's embedded by a third party or at the end of some sort of OAuth or other SSO flow, in which case the server has some extra work to do to validate that request and set context, but the angularjs application is still the same.

    If $location will be unable to do its job, it'd be nice if it threw an error telling us that explicitly, though I fear at this point that'd be a backward-incompatible change.

    (in practice, the app does otherwise work, and only failed when we added this bit to app.run())

  4. gkalpak commented on Sep 25, 2017

    Member

    Yeah, changing that would be a breaking change. (We can still consider it for 1.7, but I am not convinced it is worth it (nor that it isn't).)

    (in practice, the app does otherwise work, and only failed when we added this bit to app.run())

    It might look like it works, but could break in subtle ways (e.g. clicks on links being handled incorrectly). It really depends on what features you depend on, but you are in dangerous waters.

    You can obviously work around that, but proceed at your own risk 😁

  5. modified the milestones: Purgatory, 1.7.0 on Sep 25, 2017
  6. petebacondarwin commented on Feb 26, 2018

    Contributor

    We are going to post a warning in the console when you try to do this (rather than throwing an error). This will help developers find out why their app might not be working correctly in this case.

  7. modified the milestones: 1.7.0, 1.6.10 on Feb 26, 2018
  8. modified the milestones: 1.6.10, 1.7.x on May 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


    Back | FazBrowse Home | New Git URL