With the recent refactoring of $location service we changed this behavior
resulting in a regression.

Previously we thought that html5 mode always required base[href]
to be set in order for urls to resolve properly. It turns out that
base[href] is problematic because it makes anchor urls (#foo) to
always resolve to the base url, which is almost always incorrect
and results in all anchors links and other anchor urls (e.g. svg
references) to be broken.

For this reason, we should now start recommending that people just
deploy to root context (/) and not set the base[href] when using
the html5 mode (push/pop history state).

If it's impossible to deploy to the root context then either all
urls in the app must be absolute or base[href] must be set with the
caveat that anchor urls in such app won't work.

Closes #2762

YES. Thank you Igor.

I've found problems with this when I tried to update to 1.1.5. I wasn't able to make the jquery-ui datepicker work with angular and my base[href] because it uses anchor urls internally.

Sadly, the proposed solution of deploying to root context is not possible in my environment and I am guessing that will be unsuitable for more people. Tricky problem...

@escalant3 are you saying that your app worked before 1.1.5 without base[href]?

@IgorMinar our app at Domo worked at a /domoweb/ subdirectory on 1.1.4 but not 1.1.5. That's why this regression is so big. Even with your fix, any app not running at root will have to use the base tag which means choosing between using Angular and using third-party widgets (like jQuery UI). We are moving our app to / anyway so we'll be fine, but others won't be so lucky.

Backbone solved this problem by adding a root option to their router:

Backbone.history.start({pushState: true, root: "/domoweb/"});

Then the framework doesn't have to try to cleverly figure out the correct root, it's explicit.

I proposed something similar for Angular here #2805

LGTM

@IgorMinar it did but because I was doing a hack to prepend the routeURLs only when html5 (My app redirects to hashbang version for IE visitors). I couldn't use base[href] because it broke the jquery-ui datepicker.

The problem of the hack is that it does not work for deep linking (when landing) with 1.1.5, although it does with 1.1.4. As @geddski mentions, what I was doing was faking the root parameter that Ember.js or Backbone.js use, but only for html5 routes. I am wondering if the the Angular 1.2 router will ship something like the "root" option.

@geddski @escalant3 how do you deal with asset urls? without base[href] they have to be dynamically generated unless I'm missing something...

@IgorMinar wrote:

If it's impossible to deploy to the root context then either all
urls in the app must be absolute or base[href] must be set with the
caveat that anchor urls in such app won't work.

I'm trying to interpret this...is your comment saying that anchor tags, as in the ones that are really used to scoot around an already loaded document, will just plain old misfunction? And that applies only to cases where you're in html5 mode and not running at the root? Would it then be recommended that they be avoided in favor of some solution based on scrolling?

When I want to run in hash mode, I use this trick to get angular to put hashes in on the fly:

      //comment out the decorator function for html5mode
      //uncomment the decorator function for forced hash(bang) mode
      // $provide.decorator('$sniffer', function($delegate) {
      //   $delegate.history = false;
      //   return $delegate;
      // });
      $locationProvider.html5Mode(true);

Is that going to break? Will it be necessary? Am I just plain doing it wrong? I use it because it seems to allow me to author without concern for '#' being in hrefs, but it has thusfar not helped with running in subdirectories.

@IgorMinar My particular case is not a pure JS application. We use the back-end and absolute URLs to serve the assets.

@IgorMinar I know this isn't the complete solution, but it's part of it and solves the problem at least for projects running at root context. Can we merge?

landed as aef0980

we are still looking into solving the non-root-context situation, but AFAIK this has never worked before with anchor urls in embedded svg fragment.

@IgorMinar When are we looking to get this merged into the unstable branch? Because currently I either have to deal with completely broken routes or all anchor urls not working; neither is a particularly great state to be in. 😟

@IgorMinar this basically means it's all angular routing or no-angular routing on a particular domain? This makes it pretty hard to mix static and non-static content on the same domain and still support HTML4 hash fallback.