[Bug] New search field auto focusing prevents alternate inputs on page load

[chocmake]

Describe the bug
When an invidious page is loaded, with the recent update (afaict), the search text field is auto focused. This means any keys typed are sent to the search field even if the user isn't intending to make a search as their first action.

This has the effect of 'eating' inputs for example of the space key for page down (and Shift+space for page up), commonly used by some users like myself in various browsers. Or for playing a video on a video page using space (the prior default behavior).

Mightn't be a bug per se but behavior perhaps not considered as a result of a recent change, though the prevention of using space on video pages on initial load may be a bug since that seems unintentional. If we compare the behavior to say search engines (eg: duckduckgo.com, bing.com, etc) one can see the search field isn't auto focused so I'm not sure if this new behavior was meant to address something or not (such as a user request).

Steps to Reproduce

1. Open an instance to any page (I tested on both invidious.snopyta.org and invidious-us.kavin.rocks).
2. Observe the search field is auto focused.

Screenshots

Additional context
Tested on both Vivaldi (Chromium) and Firefox.

[SamantazFox]

Yes, that was a user request (#277).
If too many users don't like it, I guess we'll revert that and only autofocus the search field on the search page (/search).

[markozajc]

Same problem here, I'd be really grateful for a way to disable this (or to have it disabled on video pages, because it doesn't really make sense there). For now you can just patch it out:

From 0fa08e63e778d0b30d3acd1bb28b6e40c75567bb Mon Sep 17 00:00:00 2001
From: Marko Zajc <marko@zajc.eu.org>
Date: Sat, 8 Jan 2022 00:39:37 +0100
Subject: [PATCH] Disable input autofocus

---
 src/invidious/views/components/search_box.ecr | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/invidious/views/components/search_box.ecr b/src/invidious/views/components/search_box.ecr
index 4144d161..165d8623 100644
--- a/src/invidious/views/components/search_box.ecr
+++ b/src/invidious/views/components/search_box.ecr
@@ -1,7 +1,7 @@
 <form class="pure-form" action="/search" method="get">
        <fieldset>
                <input type="search" id="searchbox" autocomplete="off" autocorrect="off"
-               autocapitalize="none" spellcheck="false" autofocus name="q"
+               autocapitalize="none" spellcheck="false" name="q"
                placeholder="<%= translate(locale, "search") %>"
                title="<%= translate(locale, "search") %>"
                value="<%= env.get?("search").try {|x| HTML.escape(x.as(String)) } %>">
-- 
2.30.2

[chocmake]

Yes, that was a user request (#277). If too many users don't like it, I guess we'll revert that and only autofocus the search field on the search page (/search).

Hmm, I also use keys for scrolling on search pages (both normal queries and when searching channels). From the linked ticket I'm not sure how much consideration the OP gave the idea. The feature request tickets they reference to support their proposal (#449 and #996) were also only for autofocus for a landing page rather than everywhere.

i think as long as the keyboard is not used for anything else without having to use the mouse first there is no real reason against it.

Thing is, as we can see it does interfere with other keyboard inputs (including playback) and I've since noticed it disrupts Vivaldi's native spatial navigation since arrow keys are initially confined in the text field. It seems like they might not have realized what effect it would have.

Pressing the Tab key to focus the search seems the clearest middle ground and the standard behavior of most search fields on search-focused sites, which makes me curious if that was considered one step to much for some, though pull #513 mentions moving the mouse as annoying and doesn't mention Tab, which is quicker, making me wonder if they just weren't used to it.

[garoto]

FWIW, I'm also not a fan.

[SamantazFox]

Ok, thanks all for your feedback :)

[unixfox]

I've personally disabled the autofocus on yewtu.be

[garoto]

I've personally disabled the autofocus on yewtu.be

Thanks. I use your instance reasonably often.

I also managed to disable the search field for other public instances for the time being with a

.searchbar input[type="search"] {
    display: none !important;
    }

css directive in palemoon for the time being.

This allows me to instantly scroll the page with the keyboard on page-load, which is all I care about.

[SamantazFox]

I'm working on a fix right now. There will be a PR soon.

[SamantazFox]

@chocmake @markozajc @garoto the PR is deployed on https://yewtu.be. Mind giving a feedback?

[chocmake]

@SamantazFox looks good, cheers 👍 And from what I tried the first order Tab press is the search field, in every page type I checked, for those after quick focused access to it.

[markozajc]

@SamantazFox LGTM. My biggest problem with the current behaviour is that it eats up the space key to play the video, which this PR solves.

[chocmake]

One issue I just discovered with pull #2814 is since the search field is focused when pressing / now it prevents typing a forwardslash for a query, such as a string like f/1.4.

Maybe it could have a little extra logic to disable the key binding when the field is already focused.

[SamantazFox]

One issue I just discovered with pull #2814 is since the search field is focused when pressing / now it prevents typing a forwardslash for a query, such as a string like f/1.4.

Maybe it could have a little extra logic to disable the key binding when the field is already focused.

Oh, shoot, I though I fixed it. Thanks for reminding me! (and sorry for the late reply).