Firefox: matchChildren() issue when pathSegment contains | (pipe) char
todorpr opened this issue · comments
Basically Firefox doesn't encode | (pipe) char, actually even if it is already encoded to %7c it decodes it. This way in matchChildren():
remainingPath = segment.replace(consumedPath, '')
replace doesn't work properly as segment is decoded, whereas consumedPath is encoded.
For example if route is /one|two it becomes:
"/one|two".replace("/one%7ctwo", '') and remainingPath is wrong.
This issue causes problems to router5, since it can't identify current route properly.
This is the stack trace (router-liefecycle.js belongs to router5):
One solution in matchChildren() to change:
var segment = pathSegment;
to
var segment = encodeURI(decodeURI(pathSegment));
OK, thanks for the feedback. I'm in the process of refactoring route-node and fixing another issue. How urgent is it for you to have it fixed?
Hey, thanks for your help. Well, it's not super urgent, but it's good to be fixed soon.
Hi @troch, I saw you have released route-node v3.0.2, but this issue is not handled yet. I don't want to push you for sure, but have you planned to fix this soon, since the issues became a blocker on my side? At least maybe you can apply my suggested solution.
Will fix soon, but don't have a timeline yet
@todorpr is it when a | is in a parameter? or when it is in the path definition?
@troch hello from my side, I'm a colleague of @todorpr and the issue occurs when it is part of a path.
Our path regex looks something like /:query<(\\w{1,}(-|_|%7C|\\|)?)+> where we have multiple tokens ( words ) that can be combined by ['-', '_', '|', '%7'].
www.mydomain.com/cars-red|blue
www.mydomain.com/cars-red|blue-automatic_transmission
I struggle to replicate, I find it works OK on Firefox and elsewhere. Segments are decoded, so it seems to work whether pipe characters are encoded or not. Could you provide code to replicate?
Hmmm I see now what the issue is, creating a fix.
Fixed: troch/path-parser@d6e6d27
Will be included in router5@6
@troch i updated our application to router5@6.1.3 and I can still observe the issue with not encoded | pipe characters in Firefox.
I extended router5's react example ( chrisdoc/router5@a5703c1) to show a POC for when this is happening. I deployed the example http://ten-page.surge.sh/ , when you go to http://ten-page.surge.sh/#/firefox/red|blue via a link it opens the correct site but when you open a new tap and paste the URL you will end up on the not found page
I don't have the issue reproduced in Firefox
@troch it's a bit tricky to reproduce it, but here is a summary:
if URL is already encoded with %7c (like so http://ten-page.surge.sh/#/firefox/aaa%7cddd) it's parsed properly, but if you change last letter, press Enter and then refresh the page it fails too.
if URL contains decoded pipe | it fails http://ten-page.surge.sh/#/firefox/aaa|bbb
OK, I now see what the problem is: when a pipe is displayed in the URL, it might be encoded or not, until you manually interact with it:
- Pasting a URL with
%7Cwill work properly with%7Cbeing displayed a|(but still properly encoded). - If you copy paste that URL, it still works
- If you focus the address bar and press enter, it then becomes a
|
@troch exactly that is the issue we have observed
It was fixed with the latest release of router5 (6.2.0)