Search keyboard shortcuts hijacked?

Not sure if this is a bug or a feature (it looks new to me anyhow, move accordingly if wrong):

I usually search for content inside posts (e.g. today I wanted to search something about development on macOS inside the first long post). Now it seems that Ctrl+F/CMD+F are mapped to opening the search input set to search current thread. There are some issues/possible improvements:

  • this didn’t work in all threads
  • pressing enter 2 times on same query just hides the results, to get them back, query needs to be changed
  • possible fixes for long posts:
  • search results should be highlighted
  • add ability to fallback to browser search
  • cycle through found words

I hope search didn’t fail me and no thread about this exists yet :slight_smile:

This is intentional. You can press CTRL+F twice to get back to the browser built-in search on long topics.

And plenty more topics on the matter

1 Like

Oh, I didn’t realise this before. :worried:

Still, there is a bug with 2xEnter I guess :slight_smile:

That is indeed interesting, might be a feature request, what should it do when you press Enter a second time?

This seems to have regressed

I guess it should just refresh the results and not hide the search input. This would be a bug fix.

An improvement would be to cycle through the results (a new feature).

@tgxworld can you check and make sure search results are highlighted, that this has not regressed?

Both bugs are valid and I’ve fixed them in


@eviltrout I was looking into adding an acceptance test but I can’t quite figure out why the search menu closes in test but not in development :thinking:


@tgxworld, this seems to be impacting Notifications. I can’t click on my notifications and get to the post anymore.

Repro Steps
Click on User Profile Avatar, click any notification, fails to navigate to post, throws error

Uncaught TypeError: Cannot read property 'searchContextEnabled' of undefined
    at t.linkClickedEvent (_application-ab1012b….js:44622)
    at _application-ab1012b….js:49145
    at t.value (_application-ab1012b….js:49127)
    at t.value (_application-ab1012b….js:49142)
    at (_application-ab1012b….js:45204)
    at _application-ab1012b….js:44913
    at _application-ab1012b….js:44849
    at t.value (_application-ab1012b….js:49127)
    at s (_application-ab1012b….js:44848)
    at HTMLDocument.<anonymous> (_application-ab1012b….js:44912)

Can confirm, affecting me on both Windows (Chrome) and Android 7.1 (Chrome).

Fixed in

Our build was broken for awhile so I couldn’t deploy stuff


I am not sure off the top of my head, would require a bit more in depth tracing through the app.

Having said that, I am not sure I love defining pretender stuff in the test like that. It discourages reuse across tests in the suite, and you can’t even embed it here because it takes up so much space that I can’t see anything else :stuck_out_tongue:

It would be one thing if it was just a short stub of a response, but if using a fixture I really think it works better in its own file!


I guess using fixtures is the easiest way to get our JS acceptance tests going but one of the downsides that I find with fixtures is that they are usually too specific to a single use case and makes it hard to be reuse. In addition, fixtures are so huge that a new developer wouldn’t be able to easily understand why a fixture was added unless given the right context. That is why I prefer to add fixtures at the file level or embedded them within each individual test if you need the same route to return a different fixture. Just some thoughts I have after fighting with acceptance tests quite abit :stuck_out_tongue: