(In reply to :Gijs (he/him) from comment #8) > Yeah, this is like a much worse version of bug 1689929. I agree that this is worse of Bug 1689929 (imho this looks worse enough to be categorized as defect, Bug 1689929 was triaged as P5 and type enhancement). > Luca, any idea what to do about this? Follows some preliminary notes about an idea I've been thinking of to deal with this issue. I'm adding a discussion point for this issue to the list for our next WebExtensions API "design decisions triaging meeting", to pass by the other WebExtensions peers both this issue and the idea described below and gather some more details from based on their perspective (and also other potential ideas). In the meantime I thought it was still valuable to briefly describe it here so that we can also double-check how this idea would look from the perspective of engineers working on the Downloads internals. ### download panel to not be opened when an extension triggers a download without being handling user input #### pros - the extensions are still allowed to use the downloads API for the "periodic backups" use case - the existing extensions would keep working without having to be updated to pass a new option to prevent this issue from being triggered #### cons - requires some changes on both the WebExtensions and Downloads internals (likely not the kind that we would want to uplift, but that's just an upfront guess) - the download icon would still be flashing (but that it is tracked by the separate Bug 1689929 and I wouldn't count it as a blocking issue to consider proceeding with fixing this one) #### changes likely to be required (there may be more but this are the ones that I can think of up front): - on the WebExtensions internals side: - on the child process side, we may change [ProxyAPIImplementation.callAsyncFunction](https://searchfox.org/mozilla-central/rev/6050205f3174fd24c2b6be11c69ecd788cd2b6b3/toolkit/components/extensions/ExtensionChild.jsm#619-635) to make sure to propagate to the parent process (along with the other call details) a flag to be able to determine in the parent process if the method was called while handling user input (which we could achieve by forwarding the value got from `this.context.window.windowUtils.isHandlingUserInput` at the time we hit that internal method) - on the parent process side, we should then make sure to propagate the new `isHandlingUserInput` flag to the methods that are actually implementing the WebExtensions API methods in the parent process ExtensionAPI subclasses (so that we may get that additional flag as part of the call to the downloads.downloads API method implemented in ext-downloads.js) - on the ext-downloads.js side, then propagate the new `isHandlingUserInput` flag to the Download internals (e.g. passing it as part of the call to [`Downloads.createDownload`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1016) or [`download.start()`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1039) - on the Downloads internals side: - account for the optional flag (e.g. one named `isHandlingUserInput` or `extensionsIsHandlingUserInput` if we will prefer to only make use to it for the calls originated by the extensions) and eventually store it in the downloads object, so that we may then use it in the Downloads UI internals to determine if the downloads panel should be opened automatically or not
Bug 1759231 Comment 9 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to :Gijs (he/him) from comment #8) > Yeah, this is like a much worse version of bug 1689929. I agree that this is worse than Bug 1689929 (imho this looks worse enough to be categorized as defect, Bug 1689929 was triaged as P5 and type enhancement). > Luca, any idea what to do about this? Follows some preliminary notes about an idea I've been thinking of to deal with this issue. I'm adding a discussion point for this issue to the list for our next WebExtensions API "design decisions triaging meeting", to pass by the other WebExtensions peers both this issue and the idea described below and gather some more details from based on their perspective (and also other potential ideas). In the meantime I thought it was still valuable to briefly describe it here so that we can also double-check how this idea would look from the perspective of engineers working on the Downloads internals. ### download panel to not be opened when an extension triggers a download without being handling user input #### pros - the extensions are still allowed to use the downloads API for the "periodic backups" use case - the existing extensions would keep working without having to be updated to pass a new option to prevent this issue from being triggered #### cons - requires some changes on both the WebExtensions and Downloads internals (likely not the kind that we would want to uplift, but that's just an upfront guess) - the download icon would still be flashing (but that it is tracked by the separate Bug 1689929 and I wouldn't count it as a blocking issue to consider proceeding with fixing this one) #### changes likely to be required (there may be more but this are the ones that I can think of up front): - on the WebExtensions internals side: - on the child process side, we may change [ProxyAPIImplementation.callAsyncFunction](https://searchfox.org/mozilla-central/rev/6050205f3174fd24c2b6be11c69ecd788cd2b6b3/toolkit/components/extensions/ExtensionChild.jsm#619-635) to make sure to propagate to the parent process (along with the other call details) a flag to be able to determine in the parent process if the method was called while handling user input (which we could achieve by forwarding the value got from `this.context.window.windowUtils.isHandlingUserInput` at the time we hit that internal method) - on the parent process side, we should then make sure to propagate the new `isHandlingUserInput` flag to the methods that are actually implementing the WebExtensions API methods in the parent process ExtensionAPI subclasses (so that we may get that additional flag as part of the call to the downloads.downloads API method implemented in ext-downloads.js) - on the ext-downloads.js side, then propagate the new `isHandlingUserInput` flag to the Download internals (e.g. passing it as part of the call to [`Downloads.createDownload`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1016) or [`download.start()`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1039) - on the Downloads internals side: - account for the optional flag (e.g. one named `isHandlingUserInput` or `extensionsIsHandlingUserInput` if we will prefer to only make use to it for the calls originated by the extensions) and eventually store it in the downloads object, so that we may then use it in the Downloads UI internals to determine if the downloads panel should be opened automatically or not
(In reply to :Gijs (he/him) from comment #8) > Yeah, this is like a much worse version of bug 1689929. I agree that this is worse than Bug 1689929 (imho this looks worse enough to be categorized as defect, Bug 1689929 was triaged as P5 and type enhancement). > Luca, any idea what to do about this? Follows some preliminary notes about an idea I've been thinking of to deal with this issue. I'm adding a discussion point for this issue to the list for our next WebExtensions API "design decisions triaging meeting", to pass by the other WebExtensions peers both this issue and the idea described below and gather some more details based on their perspective (and also other potential ideas). In the meantime I thought it was still valuable to briefly describe it here so that we can also double-check how this idea would look from the perspective of engineers working on the Downloads internals. ### download panel to not be opened when an extension triggers a download without being handling user input #### pros - the extensions are still allowed to use the downloads API for the "periodic backups" use case - the existing extensions would keep working without having to be updated to pass a new option to prevent this issue from being triggered #### cons - requires some changes on both the WebExtensions and Downloads internals (likely not the kind that we would want to uplift, but that's just an upfront guess) - the download icon would still be flashing (but that it is tracked by the separate Bug 1689929 and I wouldn't count it as a blocking issue to consider proceeding with fixing this one) #### changes likely to be required (there may be more but this are the ones that I can think of up front): - on the WebExtensions internals side: - on the child process side, we may change [ProxyAPIImplementation.callAsyncFunction](https://searchfox.org/mozilla-central/rev/6050205f3174fd24c2b6be11c69ecd788cd2b6b3/toolkit/components/extensions/ExtensionChild.jsm#619-635) to make sure to propagate to the parent process (along with the other call details) a flag to be able to determine in the parent process if the method was called while handling user input (which we could achieve by forwarding the value got from `this.context.window.windowUtils.isHandlingUserInput` at the time we hit that internal method) - on the parent process side, we should then make sure to propagate the new `isHandlingUserInput` flag to the methods that are actually implementing the WebExtensions API methods in the parent process ExtensionAPI subclasses (so that we may get that additional flag as part of the call to the downloads.downloads API method implemented in ext-downloads.js) - on the ext-downloads.js side, then propagate the new `isHandlingUserInput` flag to the Download internals (e.g. passing it as part of the call to [`Downloads.createDownload`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1016) or [`download.start()`](https://searchfox.org/mozilla-central/rev/478ecccb085b7efd3c4773edb0480a7b2b16754c/toolkit/components/extensions/parent/ext-downloads.js#1039) - on the Downloads internals side: - account for the optional flag (e.g. one named `isHandlingUserInput` or `extensionsIsHandlingUserInput` if we will prefer to only make use to it for the calls originated by the extensions) and eventually store it in the downloads object, so that we may then use it in the Downloads UI internals to determine if the downloads panel should be opened automatically or not