1736182 - Input and search fields can lose focus while users are typing into them

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[MarjaE]

Attachment: Screen Recording 2021-10-16 at 3.55.17 PM.mov

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:93.0) Gecko/20100101 Firefox/93.0

Steps to reproduce:

Visit

https://archive.org/details/texts

Start typing search terms in the site's search box.

Actual results:

The first time, there's about a 50/50 chance it will lose focus.

I have coordination problems, so I can't watch the screen while typing. So I keep finding that all I've typed has lost.

Expected results:

They shouldn't lose focus while users are typing into them.

Note that so I can read on the screen, I've switched colors, fonts, and font sizes, and stopped blinking cursors. That shouldn't affect this.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Form Controls' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I can't reproduce on my Nightly fwiw :/

Comment 3

[MarjaE]

I also encounter it in troubleshoot mode, and can't test with default settings.

Comment 4

[MarjaE]

If I open the console w/ accessibility fixes, an alert saying "this.activeSection is null" appears about when the field loses focus and my typing disappears.

If I open the console in troubleshoot mode, I can't read a thing.

Comment 5

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

(In reply to MarjaE from comment #4)

If I open the console w/ accessibility fixes, an alert saying "this.activeSection is null" appears about when the field loses focus and my typing disappears.

Per https://searchfox.org/mozilla-central/search?q=this.activeSection&path=, this.activeSection seems like from FormAutoFill. Tim, do you have any idea why this.activeSection is null and maybe cause the issue mentioned in comment #0? Thanks!

Comment 6

[Tim Giles [:tgiles]]

Keeping NI open so I remember to dig into this more, but I don't think this.activeSection is causing the issue. This error has appeared for over a year IIRC. I'm not sure entirely what's causing the error to appear, I think it has something to do with the dropdown that appears on inputs.

So I think I'm able to reproduce this on my Nightly. The only time I can get it to reproduce is when I focus the search field immediately after the page does a search.

STR:

1. Navigate to https://archive.org/details/texts
2. Search some string in the "Search this Collection" box
3. Wait for page to refresh due to searching
4. Once content has refreshed, focus search input and type in text
5. If you've done step 4 quick enough, the search box will lose focus and keystrokes

This seems to be an issue with the website not preventing user interaction until all the user content is available. The website refresh and then the sidebar reloads itself after the search results have stabilized. I'm not sure where the solution to this issue would exist since we can't stop the website from reloading their markup.

:edgar, do you have any opinions on how to fix something like this? It seems like a website problem to me, I'd like your opinion on it as well

Comment 7

[Tim Giles [:tgiles]]

Yeah I'm not seeing anything that would indicate this is an issue with form autofill. Able to reproduce on mozilla-central today using the STR in Comment #6. Clearing my NI.

Comment 8

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

(In reply to Tim Giles [:tgiles] from comment #7)

Able to reproduce on mozilla-central today using the STR in Comment #6. Clearing my NI.

Thanks for looking into this!

But I wonder if the STR in comment #6 is the same as the reporter's one.
MarjaE, can you confirm if the STR in comment #6 matches yours? Thanks!

Comment 9

[MarjaE]

I can't do number 6 with the console open-- I can't scroll down get back to the text field, and type something fast enough-- so I can't compare the behavior in comment 6 with comment 0.

Comment 10

[Tim Giles [:tgiles]]

Thanks for the comment MarjaE. I'll try again but on Mac this time, since I'm not able to reproduce from comment 0 on Windows. Maybe there's something else that I'm missing on the original steps to reproduce. needinfo? myself to check this again tomorrow.

Comment 11

[Tim Giles [:tgiles]]

Okay, I can confirm the STR in comment #0 and consistently reproduce.

• Navigate to https://archive.org/details/texts
• Focus "Search this collection" input and start typing random characters, doesn't matter what the characters are
• Once the page is done loading its content (around 10 seconds given my network and machine, results may vary), the "Search this collection" input will clear its input and focus

This is because the website is injecting markup after some XHRs are complete. This causes the focus and keystrokes to be lost, since the whole section ".column-facets" is being overwritten. This ".column-facets" container is the sidebar I mentioned in comment #6.

Here's the relevant JS from the site showing the markup being injected. The file is webpack/components/facets.js.

$(() => {
  // see if page is using JS to do XHR to get facets _after_ (not during) main page load
  $('.js-facets-xhr').each(() => {
    // indeed - use the same URL w/ some flags
    let url = location.href.concat('&headless=1&facets_xhr=facets');

    // FUTURE: Might want to load FTS facets async
    const isFullTextSearch = $(this).attr('data-search-type') === 'text';
    if (isFullTextSearch) url += '&sin=TXT';

    $.get(url, (htm) => {
      // inject the markup back in by replacing the "loading.." placeholders
      const facets_markup = $(htm).find('.columns-facets').get(0).innerHTML;
      $('.columns-facets').html(facets_markup);
    });
  });
});

:edgar, tossing this back to you. Unfortunately, I don't know what we could do in this situation to prevent this from happening :/ hope the investigation helps in making a decision

Comment 12

[Tim Giles [:tgiles]]

I happened to go on this site today and tried to reproduce using the steps in Comment #11, but it seems to be fixed now on the website site. Not sure what to make of that lol.

Comment 13

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

Hi MarjaE, do you still encounter this issue? Thanks!

Comment 14

[MarjaE]

Not today, but it has been on-and-off for years.

Comment 15

[Edgar Chen [:edgar] (Parental leave until Oct. 09.)]

(In reply to MarjaE from comment #14)

Not today, but it has been on-and-off for years.

Thanks! Set to S4 tentatively, feel free to raise the priority.

And also thanks for Tim's investigation!