Backed out as part of backing out other related changesets (Bug 1944565, Bug 1710425)

Backout link

The reason for the backout was from the other bugs. We can re-land this one.

https://hg.mozilla.org/mozilla-central/rev/25f1f22c50f7

I was looking a bit at what we need here.

First observation is that file dialogs cannot be handled with the observer notification "common-dialog-loaded" used in our PromptListener.

Since we don't support automatic prompt handling in BiDi yet (Bug 1905086) and file prompts are not in scope of browsingContext.handleUserPrompt, so we can probably leave this out of this bug.

With this bug, clients will be notified about file prompts, but will have no way to interact with it. That being said we should still try to implement the event in a way that is compatible with dismissing the file prompt later on, because that requirement will come up as soon as Bug 1905086 is addressed.

I think a reasonable technical solution here would be to reuse the same pattern as the MockFilePicker used in our tests, and register another FilePicker for WebDriver BiDi, which would allow to emit events when the file picker is requested and potentially dismiss the request, or fallback to show a real filepicker instance.

https://searchfox.org/firefox-main/rev/88121de0ccd1a6e364645b9971f36c5eb00f4317/testing/specialpowers/content/MockFilePicker.sys.mjs

Gijs, do you have any suggestion on how to monitor (and potentially interact) with File Prompt dialogs for automation (WebDriver BiDi) scenarios. Do you think reusing the MockFilePicker approach could be a good solution here?

(In reply to Julian Descottes [:jdescottes] from comment #9)

I was looking a bit at what we need here.

First observation is that file dialogs cannot be handled with the observer notification "common-dialog-loaded" used in our PromptListener.

Sort of more generally: I think on all platforms our "open file" or "save file" dialogs are all OS-implemented. That is, we hand everything off to the OS, including where the dialog is on screen, styling, etc. This is frequently an issue on Linux as various desktop environments / window managers have "interesting" ideas about what features such dialogs do/don't need and then users complain to us - but we cannot in fact help.

All this to say, we cannot straightforwardly automate interacting with the "real" dialogs (we'd need a per-OS automation layer that then talks to the OS dialogs we open via those OS APIs, rather than "just" some JS/C++ bits that talk to our own dialogs).

I think a reasonable technical solution here would be to reuse the same pattern as the MockFilePicker used in our tests, and register another FilePicker for WebDriver BiDi, which would allow to emit events when the file picker is requested and potentially dismiss the request, or fallback to show a real filepicker instance.

https://searchfox.org/firefox-main/rev/88121de0ccd1a6e364645b9971f36c5eb00f4317/testing/specialpowers/content/MockFilePicker.sys.mjs

Gijs, do you have any suggestion on how to monitor (and potentially interact) with File Prompt dialogs for automation (WebDriver BiDi) scenarios. Do you think reusing the MockFilePicker approach could be a good solution here?

This type of approach sounds reasonable to me, though the exact specifics of how it hooks into "regular" file picker use may be the troublesome bit.

Thanks for the feedback Gijs! At the moment the only interaction we have in the spec for the file picker is to either: allow it to be displayed (so do nothing) or dismiss it. In the dismiss case, it's hooked from https://html.spec.whatwg.org/#common-input-element-apis:show-the-picker,-if-applicable, which means the picker should not even be displayed. So I think it's fine if we consider the picker as a black box fully driven by the OS.

I started to implement something using the MockFilePicker approach, and while that works well for detecting FilePicker openings, our spec also expects that we provide the reference to the input element which triggered the picker. And since the MockFilePicker logic lives in the parent process, it doesn't really have access to this.

So I think I need another solution, fully handled in the content process. I'm thinking about adding an event or observer notification at https://searchfox.org/firefox-main/rev/e613f4df351a21871cfeadf7d5b4043ffad157b1/dom/html/HTMLInputElement.cpp#356

mFilePicker->Open(mFpCallback);

Ideally I would need to be able to "dismiss" opening the picker with this event, but if that's too complicated to setup, I think we could also fallback to using the event in content process to detect picker openings, and use the MockFilePicker solution in the parent process to dismiss the picker.

Olli: Does it sound fine to you to introduce an event or an observer notification before the mFilePicker->Open I linked above?

FWIW, I tried a slightly different implementation, mocking the file picker in content processes. It's slightly better as I can also try to "find" the file input when I send the event, but it's very hacky and fragile, so I really think an observer notification will be the best approach here. I will try to craft a patch for this.

(Clearing the ni, thanks for the review!)

Comment on attachment 9525353 [details]
Bug 1855045 - Emit observer notification when input type file triggers a filepicker

Revision D271790 was moved to bug 1999229. Setting attachment 9525353 [details] to obsolete.

https://hg.mozilla.org/mozilla-central/rev/a438a35b0028
https://hg.mozilla.org/mozilla-central/rev/2bff294daf22
https://hg.mozilla.org/mozilla-central/rev/fd95551f7979
https://hg.mozilla.org/mozilla-central/rev/47bfa986eb39