1512818 - FF ESR 60 on Linux only: On new window or FF start, focus goes to the sidebar and not to URL bar if autofocus is set

Status: RESOLVED WONTFIX

(WebExtensions :: Frontend, defect)

Description

[aafn]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

Cf. https://github.com/aaFn/Bookmark-search-plus-2/issues/67

- Use FF ESR 60.3 on Linux
- Install a sidebar webextension add-on having an autofocus input in it
- E.g., this can be with any add-on, but for the sake of reproduction, you can use Bookmark Search Plus 2 -> https://addons.mozilla.org/en-US/firefox/addon/bookmark-search-plus-2/
- Once installed, make sure that FF is set up to start with a "blank page" or "default page" in the options
- Open a new browser window with Ctrl+N



Actual results:

If you are on FF ESR 60.3 under Linux, Keyboard focus is going to the input in the sidebar add-on

-> focus is stolen by the add-on input, while nothing user originated is activating the add-on (like pressing its shortcut). In my view, this can be a security or privacy exposure.


Expected results:

Focus should remain with the URL bar, like without the add-on, and like in FF ESR 60.3 under Windows.

Comment 1

[aafn]

Note that FF 63 normal (not ESR) under Linux does not have the problem. I didn't test with older versions under Linux.

On Windows, no version (ESR or not) has this problem.
Can't tell on Mac as I do not have any under the hand ..

Comment 2

[Gingerbread Man]

(In reply to aafn from comment #1)
> Note that FF 63 normal (not ESR) under Linux does not have the problem.

If you could find the fix range with mozregression, it would help identify which bug introduced the change and then see if uplifting to ESR is viable.
https://mozilla.github.io/mozregression/documentation/usage.html

Comment 3

[aafn]

Apparently mozregression is not working with Firefox ESR, or am I wrong ?
Should I try with normal FF, on the assumption that ESR is not different from normal Firefox on that aspect ? Just not sure of which FF version number I should look at then ..

Comment 4

[Gingerbread Man]

(In reply to aafn from comment #3)
> Should I try with normal FF

You know that the issue occurs in Firefox 60 and is fixed in Firefox 63, so you're trying to determine when the fix was introduced. This should be the resulting command line to use:
mozregression --find-fix --good 63 --bad 60

Comment 5

[aafn]

Hello, the mozregression process bisected it to:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1c52d8baf78986cb9497d48b8b88291686a681ca&tochange=c034e7ddbacdbe80ec8ce5b844e4299fcac9287c

Trace at end of the bisection process:
--------------------------------------
11:57.30 INFO: application_buildid: 20180725225713
11:57.30 INFO: application_changeset: 1c52d8baf78986cb9497d48b8b88291686a681ca
11:57.30 INFO: application_name: Firefox
11:57.30 INFO: application_repository: https://hg.mozilla.org/integration/mozilla-inbound
11:57.30 INFO: application_version: 63.0a1
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): bad
16:45.60 INFO: Narrowed inbound regression window from [081eba54, c034e7dd] (4 builds) to [1c52d8ba, c034e7dd] (2 builds) (~1 steps left)
16:45.60 INFO: No more inbound revisions, bisection finished.
16:45.60 INFO: First good revision: c034e7ddbacdbe80ec8ce5b844e4299fcac9287c
16:45.60 INFO: Last bad revision: 1c52d8baf78986cb9497d48b8b88291686a681ca
16:45.60 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1c52d8baf78986cb9497d48b8b88291686a681ca&tochange=c034e7ddbacdbe80ec8ce5b844e4299fcac9287c


Looking at the two changes, it is not obvious which one it would be, although
    Bug 1357487 Turn on OOP extensions by default on Linux
is the only one on Linux only as it seems, so would correspond best ...

Also, looking at https://wiki.mozilla.org/Add-ons/QA/Testplan/OOP-WebExtensions, this is indeed related to web extensions .. but hard to guess why running in a different process implies a different behavior on the "autofocus" input field of an add-on.

On Windows, this was activated since FF56 as I get it, which would explain why we observed this only on Linux.
(note on MAC, this is since FF61 apparently).

Hope this helps, cheers aaFn.

Comment 6

[aafn]

Confirmation that https://bugzilla.mozilla.org/show_bug.cgi?id=1357487 is the solution:

by setting extensions.webextensions.remote to true in about:config
the behavior aligns with other FF versions.

Now, if somebody could explain why Out Of the Process is changing the add-on autofocus input field effect ??

Comment 7

[Gingerbread Man]

(In reply to aafn from comment #5)
> Hello, the mozregression process bisected it to:

Thank you for making the effort.

:Gijs or :mixedpuppy, do you think there's anything left to do here? I don't expect a big change from 4 months ago to be uplifted to ESR now.

Comment 8

[Shane Caraveo (:mixedpuppy)]

I'm not certain if there were other dependencies that did not make it to ESR 63.  Kris would really be the best person to answer that.  If it is just the pref change that did not make it, it's probably easy enough to role it into whatever ESR version.  If other changes are required, probably best to leave it as-is.

Comment 9

[Shane Caraveo (:mixedpuppy)]

Ah, ESR is 60.  I'm sure that there are other problems with turning this on for linux on 60, so it will need to wait for the next major ESR release.