I'm submitting a bug report

• Library Version:
  1.3.2

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  9.4.0

• NPM Version:
  5.6.0

• JSPM OR Webpack AND Version
  webpack 4.29.0

• Browser:
  Chrome

• Language:
  TypeScript

Current behavior:
Since 1.3.2 %2B (+) in the querystring is replaced by space in the params object passed to the Activate() function.
Probably related to 957532d

Expected/desired behavior:

• What is the expected behavior?

• What is the motivation / use case for changing the behavior?

After I configured router to use PushState I can not open link in new tab using middle button. But I can do it using Ctrl + left button click because of this check. To fix it probably need to add check for event.button.

I'm submitting a bug report

Library Version: 1.0.0
Operating System: Windows Server 2012 R2 Datacenter
Node Version: 7.3.0
NPM Version: 3.9.0
JSPM/Webpack Version: N/A
Browser: all
Language: ESNext

Current behavior:
The method navigate in class BrowserHistory should always return boolean by contract(as indicated in its TypeScript source code). However, one path

if (trigger) {
  return this._loadUrl(fragment);
}

calls and returns _loadUrl, which may subsequently call and return this.options.routeHandler. This is problematic because as least given aurelia-router v1.0.2, this.options.routeHandler will be initialized with AppRouter.prototype.loadUrl, the return type of which is a Promise.

Expected/desired behavior:
BrowserHistory.prototype.navigate should always return either boolean or Promise, but not both.

this.this.replaceState(...) seems strange

also, i can't find where the replaceState function is defined.

I'm submitting a bug report

• Library Version:
  1.3.0

Please tell us about your environment:

• Operating System:
  Windows 10

• NPM Version:
  6.4.1

• Browser:
  At least Chrome 73.0.3683.75 and Internet Explorer

• Language:
  TypeScript

Current behavior:

When the URL has double slashes (example: http://localhost:9000//route?parm1=... or http://localhost:9000/route1//route2?parm1=...), history.replaceState will remove the double slashes. This will produce the following security error because the two URLs don't match anymore:

Unhandled rejection SecurityError: Failed to execute 'replaceState' on 'History': A history state object with URL [...] cannot be created in a document with origin 'http://localhost:9000' and URL [...].

Steps to reproduce
Add an extra slash to have two consecutive slashes inside any route of your Aurelia app

Expected behavior

Url should be insensitive to the number of consecutive slashes

Use Case

We have an external partner with a very long release cycle who is calling us with two consecutive slashes

Hi (and big thanks already for all the great work on Aurelia),

I've started to play around with the framework by setting up an app which router is configured with config.options.pushState = true; to use pretty URLs.

I would still like to be able to use bookmarks on my root page (such as http://host/#bookmark), and I noticed that the location was systematically turned into http://host/bookmark. # is however not stripped when using an URL other than the root location (i.e. http://host/whatever#bookmark works fine).

This seems to happen here.

Is it the expected behavior to mutually exclude bookmarks or routing on the root URL when using pushState = true ? If that's the case I'll challenge that, I think!

https://github.com/aurelia/history-browser/blob/master/src/index.js#L212

I think there is a bug on that line where 'fragment' should be 'url'. The bug that appears from this is that when I have a redirect route in a route map like:

config.map([
  { route: 'welcome',  moduleId: './welcome',      nav: true, title:'Welcome' },
  { route: '', redirect: 'welcome' }
]);

When I visit the route, '', that redirects, it makes the url look like '/#welcome' instead of '/#/welcome'. (missing a '/' after the '#')

Not sure exactly what the variable 'url' is used for, but it seems to fix it mainly because this.root is appended to it with a value of '/'. Not entirely sure what this.root is used for, so if has some other purpose, then it might just need a static '/' appended to fragment.

I guess this is a sort of feature request. I would find it very useful to have an optional parameter to the navigateBack that traverse the history until a specific route is reached.

The use case would be a looping workflow application, where once the user reaches a certain point, you'd direct them back to start over.

Perhaps something resembling this:

router.navigateBack('targetroute');

Thoughts on this? If thought to be a worth-while enhancement, I can work on a pull request.

to reproduce run the contact manager tutorial. using safari mobile on iPhone the back button does not trigger canDeactivate as expected.

this does not work on safari mobile, and on devices where the the promp is shown the browser history is not being maintained

click back
if not on safari mobile prompt shows
click cancel
click back
if not on safari mobile prompt shows
click ok
user is routed to two history locations back as back button was pressed twice(this might be a separate bug)

Expected: user is only routed one history location back. it seems like the browser history is not being maintained properly, besides the issue of the the back button triggering the prompt on safari mobile.

The default behavior of [GET] form submit is generally equivalent to that of a link click. It would be nice to have a default handler for this also.

I have noticed when using back button in IOS safari the event aggregator for router does not fire, there are quite a few tickets on back button but I think this is a different issue to the ones already logged.

I notice in desktop when clicking back button AureliaHistoryBrowser._checkUrl is called but in IOS safari its not

this.eventAggregator.subscribe('router:navigation:processing',this.saveOnRouteChanged.bind(this));

Maybe this link is relevant
https://stackoverflow.com/questions/46466618/why-popstate-doesnt-fire-my-function-when-back-button-is-clicked-mobile-ios-ch

aurelia-history-browser 1.3.2
aurelia-router 1.7.1

I'm submitting a bug report

• Library Version:
  1.3.2

Please tell us about your environment:

• Operating System:
  Windows 10

• Node Version:
  8.9.4

• NPM Version:
  6.9.0

• JSPM OR Webpack AND Version
  webpack 4.30.0

• Browser:
  all

• Language:
  all

Current behavior:
Passing a=b%26c as a view query results in {a: 'b', c: true} object

Expected/desired behavior:

• What is the expected behavior?
  Passing a=b%26c as a view query results in {a: 'b&c'} object

• What is the motivation / use case for changing the behavior?
  An encoded parameter value is expected to reach a view unchanged

I'm submitting a bug report

• Library Version:
  1.0.0

in the typings for the history class (e.g. Router.history) - there is no property previousLocation

I was expecting this property to be part of the d.ts file, at the moment I'm forced to cast Router.history to any to get the previous location.

Was this purposefully omitted?

If this was not purposefully omitted, I'm happy to make the changes to bring this into the TypeScript API

Hello (again!),

I'm using pushState=true (as well as hashChange=false but it does not seem to have any influence) and have an element defined as follows:

<a href.bind="url" dblclick.trigger="dblclick()">Double-click me!</a>

(the same issue can be observed if you replace 'dblclick' by 'click').

I would expect that whenever there is a click (as a dblcick sends 2 clicks anyway) event handler bound to the element, the event is ignored by the DefaultLinkHandler and the router does not step in.

However, whenever I double-click on the element, the router handles the event (twice!) AND click() is called.

As far as I understand in getEventInfo it's now ignored only if there is a left click and the URL is relative or root-relative. A propsed addition would be to check for the presence of click event handlers on that element.

I have made a gist here: https://gist.run/?id=2fba7f5617dd490eef561a2c07c4f6b0

The workaround I'm using for now is to only use fully qualified URLs to 'confuse' getEventInfo, but I believe I'm raising a valid point that could be fixed!

I'm submitting a bug report

• Library Version:
  1.1.0

Please tell us about your environment:

• Operating System:
  OSX 10.x

• Node Version:
  8.9.4

• NPM Version:
  5.6.0

• JSPM OR Webpack AND Version
  N/A

• Browser:
  Safari latest | iOS Safari latest

• Language:
  N/A

Current behavior:
Strictly not aurelia bug, but a Webkit bug.

The replaceState doesn't work properly on Safari (on both macOS and iOS) when <base href=".."> is in use. It manifested as malfunctioned browser back/forward buttons in aurelia app with pushState turned on.
aurelia/router#574

To reproduce the issue on Mac, create index.html file with content

<!DOCTYPE html>
<html>
  <head>
    <title>test</title>
    <base href="/">
  </head>
  <body></body>
</html>

Serve the static file with http-server in the file directory (npm install -g http-server).

Open http://127.0.0.1:8080 with Mac Safari, do following in dev console (one by one, not in one shot).

history.pushState({}, "", "/one"); // browser url shows http://127.0.0.1:8080/one
history.replaceState({}, null, null); // or ({}, "", null) or ({}, "") or ({}, null)
history.pushState({}, "", "/two"); // browser url shows http://127.0.0.1:8080/two
history.back(); 
// oops, browser url shows http://127.0.0.1:8080 instead of http://127.0.0.1:8080/one

To bypass this Safari bug, you have to feed current url back to replaceState:

const url = document.location.pathname + document.location.search + document.location.hash;
history.replaceState({}, null, url); // or ({}, "", url)

Expected/desired behavior:

• What is the expected behavior?
  Expect back/forward buttons on Safari to work.

• What is the motivation / use case for changing the behavior?
  The proposed dirty fix is to bypass Webkit bug, maybe should only apply to Safari?

cc @jwx @davismj

I'm submitting a bug report

• Library Version:
  1.3.0

• Browser:
  all

• Language:
  all

Current behavior:
When the casing of root (which is the baseUrl passed on from the router) does not match to current root, the application fails to navigate to any route.

• What is the expected behavior?
  Navigation should not rely on exact casing of the root.

• What is the motivation / use case for changing the behavior?
  The route-recognizer is case-insensitive (with an option to specify individual routes as case-sensitive, see aurelia/router#271). The baseUrl should probably have similar behaviour, or at least have an option to specify it as case-insensitive.

As far as I could tell, there are two places in history-browser that are affected: