Pressing enter on search results creates invalid url

[mahomedh]

I wonder if anyone could provide me with some guidance on an issue I have with search.

Basically if I am on any page apart from the root/welcome page, and I type a search and press the enter key, it appends the search result url to the current page's url. i.e.

Current Page: https://wiki.example.com/page-1/
Search for: Page 2 term
Press enter and it goes to: https://wiki.example.com/page-1/page-2/
The correct URL (and if I hover over the first result) should be: https://wiki.example.com/page-2/

Now I believe this is an issue with how I have the site hosted on S3 with CloudFront, because this issue cannot be replicated on the demo site or when run locally. I'm just wondering if anyone has any ideas or tips on what I can do to troubleshoot this please. Thanks.

[mahomedh]

I've tried to do a bit more digging. Let me start with a better example.

Current navigation is

Welcome
FolderA
  - PageA

If I go to PageA and do a search for a word in the "Welcome" page, hovering over the result that comes gives me the full URL https://wiki.example.com/#welcome-to-my-wiki but when I inspect that result, the href is ../../#welcome-to-my-wiki.

If I click the result, I correctly go to https://wiki.example.com/#welcome-to-my-wiki but if I press enter, I will go to https://wiki.example.com/FolderA/PageA/#welcome-to-my-wiki

The only thing that I can find/think of is that when pressing enter, the event handler (seems to be retype.js) is only sending the result's relative path ../../#welcome-to-my-wiki and so the browser (or maybe CloudFront) is prepending the full url of the current page https://wiki.example.com/FolderA/PageA/ because it's unable to calculate the correct relative url. Where as when you hover over the result/click the result, the browser is able to correctly determine that the ../../ translates to https://wiki.example.com/ and appends that.

Is there any way to fix this or force Retype to put in static URLs instead of relative? After all, the url setting is configured in the project config so it should be able to set the full path from that.

[geoffreymcgill]

Hi @mahomedh. Thanks for reporting this issue. We are investigating and will try to fix right away. I think we know where the issue is happening.

As a work around, could you try adding the following config to your projects retype.yml file.

generator:
  paths: root

Please let me know if the above config helps work around the problem, at least until a permanent fix can be released.

[mahomedh]

Thanks for looking into this and for the suggestion. Unfortunately it doesn't seem to have helped.

The change has caused the relative path to change from ../../#welcome-to-my-wiki to /#welcome-to-my-wiki. But it hasn't changed the behaviour as per my second post above.

Let me know if you want me to setup a test site for you so can try any changes. I can have it ready in a couple of hours.

[geoffreymcgill]

Let me know if you want me to setup a test site for you so can try any changes. I can have it ready in a couple of hours.

Actually, this would really help. I need to dig into this issue in more detail today, although on my first attempt I was not able to reproduce the issue.

Does this issue occur across multiple different web browsers? or is specific to one web browser?

Any idea on what configuration with CloudFront might be causing this?

Is index.html included as a default directory file name? I assume it is otherwise https://wiki.example.com/FolderA/PageA/ would not work.

I am also assuming you are not able to reproduce this behaviour on retype.com?

[DannyBen]

I just started to encounter this as well.

The only thing I changed, was to move some captions from being H2 to being H3.

Before (works)	After (broken)

Now, when searching for strings that moved to H3, and pressing Enter, I get an error, since it tries to go to a page that does not exist.

This can be reproducible by checking out the next branch from my bashly documentation.

Reproduction steps:

Expected Behavior

1. Go to https://bashly.dannyb.co/usage/settings/ (notice the sub page, can be anything but root or the page that is the search target)
2. Press /
3. Type alias and press Enter
4. You will be redirected to https://bashly.dannyb.co/configuration/command/#alias, which is correct

Actual Behavior

1. Using the checked out branch, do the same as steps 1-3
2. You will be redirected to http://localhost:3000/usage/settings/configuration/command/#alias, which is incorrect

Note: It acts as if the form submission is not prevented (or it otherwise performs two tasks). It can be observed when searching for something that exists on the same page you are on. It will first start scrolling to it, and then "submit the form" and go to that invalid URL.

[geoffreymcgill]

@DannyBen Thank you for this detailed explanation on how to reproduce. We are looking into this right now and hope to fix right away. I will keep this thread updated with our progress.

[DannyBen]

I don't want to steer you in the wrong direction.... I noticed that my master branch locally is behaving the same (and I am positive it worked fine before). Not sure if it is caching from my bad build, or some other weirdness. I am still investigating myself.

[DannyBen]

Ok - found something I think:

1. I can confirm this is also reproducible on the retype site itself, when served locally (but not in production).
2. When serving with retype run (which I never use due to the fact it opens a terminal browser - Disable browser open/refresh upon `retype watch` #323), it works
3. When serving with a standard HTTP static server, it breaks. I am using httpme but I suspect any static server will break just the same.

Maybe the difference is how it is served, and not what it contains.

[geoffreymcgill]

@mahomedh & @DannyBen Looks like we have this defect fixed. Still a few more tests to run. We will likely make a new release early next week.

[DannyBen]

Nice, thanks. I am curious as to why it was reproducible locally and not in production.

[DannyBen]

Is there any update on this problem?

I can now update that this bug seems to be easily reproducible on my own sites, and on retype.com in production (and not only locally as seemed before).

Reproduction steps

• Go to https://retype.com
• Type / to open the search box
• Type brand and press Enter
• You will be redirected to a working page
• Type brand again and press Enter
• You will be redirected to https://retype.com/configuration/project/configuration/project/#branding - which is a 404 page

[geoffreymcgill]

We're going to try and release v2.4 right away. Looking into it today.

[geoffreymcgill]

Retype v2.4.0 has been released and includes the fix for this search results defect.

Hope this helps.

[mahomedh]

@geoffreymcgill I can confirm this has fixed the issue for us. Thank you for sorting it.

[DannyBen]

Me too. Confirmed as fixed.