print dialog does not lock compose window completely
Categories
(Thunderbird :: Message Compose Window, defect)
Tracking
(Not tracked)
People
(Reporter: myaddons, Assigned: TbSync)
References
Details
Attachments
(1 file)
The new print dialog does not lock the compose window completely. It is still possible to interact with the menu and the toolbar buttons.
For example: You can still save or send the message and you can attach a file. You can still change the delivery format or the priority. And you can even fiddle with the editor, i.e. the body of the message, via "Tools -> Quote Message". Multiple menu entries are still enabled, but seem to have no effect.
You can also start a spellcheck, which opens a (modal) window above the print dialog, but the context, i.e. the body of the message, is behind the print dialog and therefor not shown - leaving the spellcheck in a less than ideal state.
I think the compose window should get locked completely in this case - including locking all menus and toolbars.
Reporter | ||
Comment 1•2 years ago
|
||
There are multiple places where a global locking of the message compose window is needed, e.g.: Bug 1758469 and Bug 1758470. And in case of an "locking overlay" in the compose window as an alternative to modal dialogs - discussed in Bug 1607192. The solution should ideally cover all these use-cases.
Assignee | ||
Comment 2•1 month ago
•
|
||
The open/close Promises of PrintUtils are not returned from the m-c
component and are not accessible. The only access handle I could find is
the browser itself. Attaching the two callback methods is a very simple
solution, but is it any good?
This patch locks the composer (for example menus, action buttons
and commands) while the print preview modal dialog is shown.
Depends on D203940
Updated•1 month ago
|
Assignee | ||
Updated•1 month ago
|
Updated•1 month ago
|
Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/b00f8a94a76e
Lock compose window during print preview. r=aleca,vineet
Description
•