1607192 - [API Request] Add CreateType "dialog" or "modal" to browser.windows.create()

Status: RESOLVED DUPLICATE of bug 1848190

(Thunderbird :: Add-Ons: Extensions API, enhancement)

Description

[Alexander Bergmann]

Opening a new window using browser.windows.create() within a composeAction works fine. However, the new window apparently can either be a "normal" or a "popup" window. Both let the user still interact with the parent window.

For my add-on Mail Merge it would be very useful to open a modal dialog window to prevent the user from interacting with the parent window, i.e. the Message Compose Window.

As this could also be handy for other add-ons I think another WindowType "dialog" or "modal" should be added to create a new modal dialog window programmatically using browser.windows.create().

Comment 1

[Alexander Bergmann]

It should have been CreateType instead of WindowType.

Comment 2

[Óvári]

@darktrogen @jorgk Are you able to advise if this bug report will gain traction before the release of Thunderbird 78 ESR? If there is already a way to open dialogs (instead of normal windows) with the current WebExtension APIs it would be appreciated if you would provide assistance. Thank you

Comment 3

[Geoff Lankow (:darktrojan)]

It could happen, although I can't promise anything.

Comment 4

[Alexander Bergmann]

At the moment it is possible to create a new window via messenger.windows.create() and then wait for the window to be closed - like it is done in the awaitPopup Example. But unfortunately the user can still interact with the message compose window in the meantime.

A locking mechanism, which locks the compose window completely, is also needed for Thunderbird itself in various places - see Bug 1758469 and Bug 1758470. Making this mechanism available via a WebExtension API, e.g. messenger.compose.lock(tab) and messenger.compose.unlock(tab), would be very welcome and should be easy to implement.

A viable alternative - possibly even better than modal dialogs - could be to create a "modal" overlay, in which an iframe with the popup.html of the add-on can be loaded into, e.g. via messenger.compose.overlay.create(). (Like it is done for the new print dialog.)

The additional benefit of creating an overlay compared to opening a new window or tab is, that the connection - from a user perspective - between the compose window and the popup is very strong in case of an overlay. Of course the overlay should also have the possibility to lock the compose window.

With the two additions - a locking mechanism and a "modal" overlay - a "modal" dialog would no longer be needed for my own add-on Mail Merge.

Comment 5

[Mark Banner (:standard8)]

(In reply to Alexander Bergmann from comment #4)

A locking mechanism, which locks the compose window completely, is also needed for Thunderbird itself in various places - see Bug 1758469 and Bug 1758470. Making this mechanism available via a WebExtension API, e.g. messenger.compose.lock(tab) and messenger.compose.unlock(tab), would be very welcome and should be easy to implement.

Why does the compose window need locking? This seems like a potentially poor user experience - either what you're doing is taking too long, or you are maybe trying to do things that you should be doing in the background. If you do them in the background, then providing a way to recover if there's an issue seems like the sensible way.

Ideally Thunderbird would have moved to send in background - however there were a few challenges so it so far has never quite got there, but it would be a much better UX than blocking the UI.

I'm not saying that this can't be done, but I think it is worth a discussion/exploration of alternatives.

Comment 6

[John Bieling (:TbSync)]

This is planned for the next ESR. The better bug describing the planned feature is Bug 1848190.