$anchorScroll only working on second click

[jimknight]

http://plnkr.co/qw6Wtikz1hwgbGMHyqqY

[petebacondarwin]

The problem here is that by default there is no hashPrefix specified on the $locationProvider, which means that in your sample, the URLhttp://run.plnkr.co/plunks/qw6Wtikz1hwgbGMHyqqY/#Ipsum gets interpreted as a hash bang path, i.e. http://run.plnkr.co/plunks/qw6Wtikz1hwgbGMHyqqY/#/Ipsum, where $location.path() === 'Ipsum' and $location.hash() === ''.

The second time you click the link then the path gets interpreted as http://run.plnkr.co/plunks/qw6Wtikz1hwgbGMHyqqY/#/Ipsum#Ipsum, where $location.path() === 'Ipsum' and $location.hash() === 'Ipsum'.

A workaround for this is to provide a hashPrefix to $locationProvider as in http://plnkr.co/edit/0FJzVI86GNG15ga5J8Ie?p=preview

app.config(function($locationProvider) {
  $locationProvider.hashPrefix('!');
});

But I have a feeling that there is a bug in here somewhere...

[gkalpak]

Just a sidenote: Note that since v1.4.0-rc.0, you can pass a hash explicitly to $anchorScroll. E.g.:

$anchorScroll('Ipsum')

but it doesn't update the $location.hash, so won't work for deep linking.

@petebacondarwin, basically, when setting $location.hash(xyz) and there is no # (which is legitimate when the path is empty), $location will set the path to xyz (instead). This sounds like a bug indeed.
Couldn't $location.hash check for the existence of # (in non-html5 mode) and add it before setting the hash ?

E.g.:

// Now:
www.example.com/ + $location.hash('xyz') === www.example.com/#/xyz

// Proposed:
www.example.com/ + $location.hash('xyz') === www.example.com/#/#xyz

[jimknight]

Would the back button work with explicit?
On Apr 29, 2015 8:22 AM, "Georgios Kalpakas" notifications@github.com
wrote:

Just a sidenote: Note that since v1.4.0-rc.0, you can pass a hash
explicitly to $anchorScroll. E.g.:

$anchorScroll('Ipsum')

but it doesn't update the $location.hash, so won't work for deep linking.

@petebacondarwin https://github.com/petebacondarwin, basically, when
setting $location.hash(xyz) and there is no # (which is legitimate when
the path is empty), $location will set the path to xyz (instead). This
sounds like a bug indeed.
Couldn't $location.hash check for the existence of # (in non-html5 mode)
and add it before setting the hash ?

—
Reply to this email directly or view it on GitHub
#11749 (comment)
.

[jimknight]

I've been having issues also where I can get things to work with the anchorScroll but with an offset, it has this flashing problem. It's a bummer, I'm deep into this project and they use a lot of anchor tags and I'm using a fixed header for a phonegap biz app. I'm seriously considering dumping angular for the project just because I can't get around this issue.

[gkalpak]

The explicit hash, only scrolls to the anchor. It doesn't change the URL, so it doesn't affect the history (so back button won't work).

What issues do you have with the offset ? The flashing issues is related to $location.hash() and should happen with or without the offset.

[jimknight]

I haven't worked up a plunker for the offset issue. I was just hoping that if this flashing issue worked with $location.hash then it would solve my other issue. And the issue for me is inconsistent. For some pages it works ok and for some not and I haven't figured out what it might be. One thing that made me wonder was finding someone talking about timing issues with when the content loads. Because the other thing is I'm loading in pages using the router into an ng-view. So I'm taking user content and building out just content pages and inserting them into ng-view and a lot of these pages have the anchor tags. There is something in that brew that's causing me these problems. Sorry I don't know more yet and thanks for asking.

[petebacondarwin]

I think this problem is based around the crazy way the browser URL updates are captured and how we then try to massage them in HashBangLocation mode.

There are quite a few other issues, which I suspect are related to this in some way: #11486, #11693, #11656, etc...

We need to have a good hard look at this part of the location service. I will spend some time this afternoon on it. @gkalpak it would be great if you were online to bounce ideas off.

[petebacondarwin]

I believe this is now fixed in master. See http://plnkr.co/edit/l8ICzAJEuJqL68mR71R1?p=preview

Either by 6903b5e or more likely f81ff3b

[petebacondarwin]

Indeed from testing different commits, I believe it is f81ff3b, which fixed it.