1610141 - "Find as You Type" blocks typing in devtool extensions inputs

Status: VERIFIED FIXED

(WebExtensions :: Developer Tools, defect, P2)

Description

[Mojtaba Izadmehr]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

1. Turn on "Find as You Type"
2. Open a Devtool extension of your choice, which also has a text input such as (react-devtools, redux-devtools, Vue.js devtools, Vue Performance Devtool)
3. Try to type in one of the text fields such as filter

Actual results:

It doesn't type! Just nothing...

Expected results:

It should type.
I checked the code of react-devtools for example, it uses event.preventDefault() on text inputs. However, for some reason, it is not working.

Comment 1

[Mojtaba Izadmehr]

Attachment: demo of the problem in a small devtool extension

I also created a simple Firefox devtool extension to test it with vanillaJs, the problem also exists there too.

The interesting point is that inside the firefox devtool source code, this problem does not exist, and they simply add the event listener for input, and only external extensions suffer from this.

Comment 2

[Alin Ilea, Desktop Test Engineering]

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

Hi,

I have managed to reproduce this issue on latest FF release 72.0.2, Beta 73.0b8 and latest Nightly build 74.0a1 (2020-01-23) using Mac OS 10.15 and Windows 10 using the extension from comment 1.
Further, I will move this over to a component so developers can take a look over it. If this is not the correct component please feel free to change it to an appropriate one.

Thanks for the report.

Comment 3

[Luca Greco [:rpl] [:luca] [:lgreco]]

I reproduced this issue locally (thanks a lot Mojtaba, the minimal test extension has been very helpful) and looked into it a bit:

it looks that the extension devtools panel does not receive the events because the FindBar internals are intercepting those events as they are received for "chrome://browser/content/webext-panels.xhtml" ([1]) and then it is calling event.preventDefault(), and so the extension page never receives those events.

I have quickly tried to early exit from FindBarContent's passKeyToParent if the event target's ownerGlobal is "chrome://browser/content/webext-panels.xhtml" and that seems to prevent the issue (and the input element inside the devtools panels keeps receiving the keypress events as expected even while the findbar is open and find-as-you-type feature is enabled.

Hey Mike,
who may be a good person to discuss about FindBarContent and evaluate if just ignoring the events related to the webextensions webext-panels.xhtml ([2]) in FindBarContent's passKeyToParent would be a reasonable solution or if we need to look into some other ways of preventing this isssue?

---

[1]: "chrome://browser/content/webext-panels.xhtml" is a chrome privileged page living in the parent process, inside it we append the browser elements that are loading the actual extension pages related to sidebar and devtools panels
[2]: and eventually other similar "chrome urls that contains webextension pages", e.g. I haven't tried yet but it is not unlikely that options page (embedded in the about:addons page) and the browserAction/pageAction popup pages may have similar issues.

Comment 4

[Tooru Fujisawa [:arai]]

regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=91f7769b3d7ec17aa11f7a8ada7104f5b4cec38d&tochange=39e19afc797d310f568447eae7054789e641b591

looks like a regression from bug 1539979

Comment 5

[Mike de Boer [:mikedeboer]]

That person would be Neil, who recently made the findbar Fission-compatible!

Comment 6

[Neil Deakin]

Do you simply want to have the FindBar actor disabled for all extensions? There is a 'remoteType' flag that can be added to actors but it unfortunately is an opt-in rather than an opt-out flag.

Comment 7

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Neil Deakin from comment #6)

Do you simply want to have the FindBar actor disabled for all extensions? There is a 'remoteType' flag that can be added to actors but it unfortunately is an opt-in rather than an opt-out flag.

I think that it would makes sense to leave the FindBar actor to work as usually for the extension pages loaded in a tab (e.g. when loaded as a top level window, when the remoteType would be "extension", or when it is loaded as a sub-frame of a regular webpage top level window, when the remoteType would be "web")

but disable it for the extension pages that are not loaded in a tab (e.g. an extension devtools panel is one case, but it may also make sense for the extension browserAction/pageAction popup window and the extension sidebar if they are affected by the same issue, I need to double-check this explicitly).

Based on Comment 4 this seems to have regressed when we started to set type: "content on the devtools toolbox frames, and so I wouldn't exclude that this may only affect the extensions devtools panels (and not the extension sidebar or browserAction/pageAction popup windows).

I'm going to double-check if that is the case (the issue is only affecting the extensions devtools panels) and if there is a chance to actually fix it at a DevTools toolbox level (instead of special casing the extension devtools panels in the FindBar internals).

Comment 8

[Neil Deakin]

I think this, along with a number of related issues would be solved by implementing the 'group' flag that legacy actors support. This would limit the findbar actor to just the browsers from that group, which would typically mean just the main browser elements , but not extension popups or sidebars. This is covered by bug 1557118.

Comment 9

[Tomislav Jovanovic :zombie]

Wouldn't you be able to ask the parent from the child actor what kind of page it is, and show/hide the find bar as appropriate?

Comment 10

[Neil Deakin]

So for the findbar, we want the actor to be created in the context of 'web' or, in fact, anytime it is used in a regular tab. However, when loaded in an extension panel, the actor does not apply. The findbar is also used in some mochitest-chrome tests, where a browser type="content" is used, but the remoteType is empty, but we still want the actor to apply.

Actors can currently be filtered based on their remote type, but I don't think the remoteType filter can handle this particular arrangement.

Options:

1. Modify the remote type filter to allow more specific filtering
2. Support an additional filter type. The legacy actors check the messagemanagergroup attribute on the browser element, and can apply only to regular tabs.

Nika, any thoughts here?

Comment 11

[Nika Layzell [:nika] (ni? for response)]

Interesting! I wasn't aware of the messagemanagergroup attribute.

A quick search suggests that messagemanagergroup exists only to be set to "browsers" when used for content browsers on desktop, and is then used to select the parent MessageManager which is used when communicating with the content process.

I believe it would be possible to have an attribute like this which identifies whether or not the browser is a standard content browser on the BrowsingContext, and have this attribute be available as a filter when defining JSWindowActors. What sort of stuff would this attribute be used for generally, and do you think it would be useful to have it be a generic string, like it is today, or would a boolean be fine?

Comment 12

[Neil Deakin]

It would need to handle at least the four cases listed in https://bugzilla.mozilla.org/show_bug.cgi?id=1557118#c2, but I think we only need to distinguish between the main content browser and other usages. The findbar, for example, currently needs to be available for 'browsers' and mochitest-chrome tests. We can annotate the <browser> elements in the tests with an attribute however, so I think a boolean would suffice for this.

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Ok. That makes sense. I think it would be reasonable to include the messagemanagergroup attribute on a BrowsingContext, and have that information bubbled around so that it can be used by JSWindowActor matchers. We'll look into adding a feature like that in bug 1557118.

Comment 14

[Neil Deakin]

Attachment: Bug 1610141, findbar should only apply to the main browsers and tests, r=mikedeboer

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/339d745c0f49
findbar should only apply to the main browsers and tests, r=mikedeboer

Comment 16

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/339d745c0f49

Comment 17

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in latest Nightly 76.0a1 (build id: 20200401212659) using the extension from comment 1, I am able to type in the input field.