1977581 - When inserting image into new e-mail, Thunderbird brings main window to front

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect)

Description

[Axel]

Attachment: Inserting image brings main window to front.gif

When composing an e-mail, if an image is added to the e-mail using the Insert > Graphic menu item and dialog, Thunderbird brings the program main window to front. This should not happen. Commonly, users want to continue composing their e-mail draft in the New E-Mail window after inserting images to the draft.

Comment 1

[Axel]

Attachment: Inserting image brings main window to front.gif

Comment 2

[Wayne Mery (:wsmwk)]

What version are you using?

Comment 3

[Axel]

It's 140.0.1 (latest release). I downloaded and installed Thunderbird yesterday.

Comment 4

[Corey Bryant]

I wasn't able to recreate this on 140.0.1 on Ubuntu 24.04. What OS are you using?

Comment 5

[Axel]

Thank you for trying to reproduce the issue. I'm using Windows 10x64.

Comment 6

[Neftha]

Same here: TB 140.0.1 (german) on windows 11.

New compose mail window, insert image using using the menu (Einfügen > Grafik).
After inserting the image, the compose window is no longer the top window - it drops to a lower layer and focus is set to now top window.
The top and now focused window is not always the thunderbird main window - can be any window I used meanwhile; seems to be the last active window:
(1) Thunderbird, open new mail, insert image -> thunderbird main window is on top
(2) Thunderbird, open new mail, switch to explorer (or any other application), switch back to compose window, insert image -> last application window is now in foreground and focused.

Comment 7

[Corey Bryant]

Vlad/Ramona, can you recreate on Windows?

Comment 8

[Ramona Gavrilescu]

Hello Corey!

We checked and were able to reproduce this issue.
We tested on Win 10, TB 140.0.1esr(20250709213912).

We tried to find a regression range.
It seems the last good build was from 2024-06-19 and the first bad build was from 2024-06-20
I could not find a culprit as the bisection kept skipping builds.

We also checked on macOS Sequoia and Ubuntu 24 and it’s not reproducible

Comment 9

[Hartmut Welpmann [:welpy-cw]]

This behavior is triggered by opening the file picker dialog (the same happens with 'Format'->'Page Colors and Background'). Maybe regressed by bug 1902315, see also bug 1903605.

Comment 10

[Axel]

I don't know which framework you are using, but perhaps it may help that the IModalDialog::Show() method accepts a handle to the parent (owner) window.

The owner window is the one supposed to be blocked while the dialog is opened and given focus to after the dialog closes.

Perhaps the handle provided to this method is incorrect?

Comment 11

[Hartmut Welpmann [:welpy-cw]]

(In reply to Axel from comment #10)

I don't know which framework you are using, but perhaps it may help that the IModalDialog::Show() method accepts a handle to the parent (owner) window.

The owner window is the one supposed to be blocked while the dialog is opened and given focus to after the dialog closes.

Perhaps the handle provided to this method is incorrect?

I think that's rather a question for Emilio.

Emilio, can you give us some insight about this bug?

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Sure, can you link me to the code that's launching the "insert image" modal? I don't know Thunderbird's code by heart :)

Comment 13

[Hartmut Welpmann [:welpy-cw]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #12)

Sure, can you link me to the code that's launching the "insert image" modal? I don't know Thunderbird's code by heart :)

The "Image properties" dialog is opened with https://searchfox.org/comm-central/rev/915ed960a38067fc7be0636e30f34a23e8fc1c93/mail/components/compose/content/ComposerCommands.js#1384-1389, the file picker on top that with https://searchfox.org/comm-central/rev/915ed960a38067fc7be0636e30f34a23e8fc1c93/mail/components/compose/content/dialogs/EdImageDialog.js#222 (see also https://searchfox.org/comm-central/rev/915ed960a38067fc7be0636e30f34a23e8fc1c93/mail/components/compose/content/dialogs/EdDialogCommon.js#356).

Comment 14

[Emilio Cobos Álvarez [:emilio]]

So... I can't repro this on Linux. Looking into this, this is most likely caused by bug 1902315. This chunk definitely used to run when exiting the modal loop on windows, and I missed that we were passing true to aActivate which means that that call also had the side effect of activating the window.

Comment 15

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1977581 - Keep activating the parent window on Windows when destroying a child. r=#win-reviewers

Bug 1902315 removed a PlaceBehind call here, which in this case happened
to also activate the window (via the aActivate = true parameter).

Keep raising the window manually, but with simpler APIs.

Comment 16

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1977581 - Cleanup nsIBaseWindow::GetMainWidget usage. r=#win-reviewers,smaug

AppWindow::GetMainWidget() is just mWindow. Add a helper to simplify
GetMainWidget() usage and use it across the tree, simplifying users.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1aa98365aff2
https://hg.mozilla.org/integration/autoland/rev/7667a5c661d0
Keep activating the parent window on Windows when destroying a child. r=win-reviewers,handyman

Comment 18

[Emilio Cobos Álvarez [:emilio]]

Can you confirm the patch works for you? If so we should probably uplift it.

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8cd79d0bd407
https://hg.mozilla.org/integration/autoland/rev/e7d4a89b6b63
Cleanup nsIBaseWindow::GetMainWidget usage. r=smaug

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9d7ea6236b2f
https://hg.mozilla.org/integration/autoland/rev/d77be007c6d9
Fix non-unified build bustage.

Comment 22

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/7667a5c661d0
https://hg.mozilla.org/mozilla-central/rev/e7d4a89b6b63
https://hg.mozilla.org/mozilla-central/rev/d77be007c6d9

Comment 23

[Hartmut Welpmann [:welpy-cw]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

Can you confirm the patch works for you? If so we should probably uplift it.

With Thunderbird Daily 143.0a1 20250806104453 this appears to be working as expected again. So I think uplifting this to ESR would be much appreciated.

Maybe Ramona can verify this, just to be sure.

Comment 24

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9503001 [details]
Bug 1977581 - Keep activating the parent window on Windows when destroying a child. r=#win-reviewers

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: restores previous behavior relevant for Thunderbird
• User impact if declined: comment 0
• Fix Landed on Version: 143
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): While not totally trivial, it restores pre-existing behavior from the regressing bug in a more straight-forward way.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Might be worth a Beta uplift request also?

Comment 26

[Emilio Cobos Álvarez [:emilio]]

Comment on attachment 9503001 [details]
Bug 1977581 - Keep activating the parent window on Windows when destroying a child. r=#win-reviewers

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: see above
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See above
• String changes made/needed: none
• Is Android affected?: No

Comment 27

[Dianna Smith [:diannaS]]

Comment on attachment 9503001 [details]
Bug 1977581 - Keep activating the parent window on Windows when destroying a child. r=#win-reviewers

Approved for 142.0rc1

Comment 28

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/6439762a2a6b
https://hg.mozilla.org/releases/mozilla-beta/rev/137e4d4d7368

Comment 29

[Dianna Smith [:diannaS]]

Comment on attachment 9503001 [details]
Bug 1977581 - Keep activating the parent window on Windows when destroying a child. r=#win-reviewers

Approved for 140.2.0esr

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/a511f36cca85

Comment 31

[Ramona Gavrilescu]

Confirm this as verified fixed on TB 143.0A1(20250811095431)
Will check again once is available in TB 140.2.0esr