369482 - Password dialogue in a different desktop than composition window

Status: RESOLVED DUPLICATE of bug 388242

(Thunderbird :: Message Compose Window, defect)

Description

[Robert Rothenberg]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.1) Gecko/20060601 Firefox/2.0.0.1 (Ubuntu-edgy)
Build Identifier: version 1.5.0.9 (20070103)

When using a system with multiple desktops (e.g. Gnome, Xfce, KDE), if TB is open in one desktop, but one writes and sends a new e-mail message in another desktop, the password dialogue will show up in the same desktop as the original TB window, and not the message composition window.  If the user is unaware of this, it will appear that TB is trying to connect to the server to send mail, but not conecting.  There is no indicator as to what TB is waiting for.

Reproducible: Always

Steps to Reproduce:
1. Use a window manager/desktop manager with multiple desktops (e.g. Xfce)
2. In one desktop, launch TB
3. In another desktop, open Firefox or another e-mail program that will
   launch a TB composition window when clicking on a mailto link
4. A composition window should appear in the second desktop. Enter a message
   and send it (from an account that requires a password to send mail).
Actual Results:  
The password dialogue appears on the first desktop. No message is apparent in the composition window on the second desktop.

Expected Results:  
A password dialogue should appear on the same desktop that the composition window was in.

I am using Xfce 4.4.0 on Ubuntu 6.10 (Edgy).

Comment 1

[Wayne Mery (:wsmwk)]

if anyone still see this problem using a current version please comment with your version number and steps to reproduce.

if you no longer see the problem, please cite your version and close the bug or comment

Comment 2

[Joshua Cranmer [:jcranmer]]

RESO INCO per lack of response to last question. If you feel this change was made in error, please respond to the bug with your reasons why.

Comment 3

[Robert Rothenberg]

(In reply to comment #1)
> if anyone still see this problem using a current version please comment with
> your version number and steps to reproduce.

Same steps to reproduce as given above.

Linux (Ubuntu Hardy) TB 2.0.0.17 (20080925)

Comment 4

[Joshua Cranmer [:jcranmer]]

Please remove the closeme tag if you reopen such a closed bug. It messes up my queries.

In any case, I was unable to reproduce with TB 2.0.0.17 using Fluxbox on a Debian testing installation.

Comment 5

[Robert Rothenberg]

I can reproduce it on Xfce 4.4.2 but not with Gnome 2.22.3.

Comment 6

[Robert Rothenberg]

Actually, I take that back for Gnome.

In Gnome, when I click on a mailto link, I get the password dialog in the desktop with the web browser and composition window (Desktop 1), not the desktop with TB (Desktop 2).  So I cancel the password dialog and message composition, since I thought the bug didn't occur in Gnome.

But then I go back to Desktop 2 to send another e-mail, and the password dialog came back up in Desktop 1.

Comment 7

[Robert Rothenberg]

(In reply to comment #4)
> In any case, I was unable to reproduce with TB 2.0.0.17 using Fluxbox on a
> Debian testing installation.

Can you reproduce the case for comment #6 in Fluxbox?

Comment 8

[Robert Rothenberg]

An issue has also been submitted to the Xfce bug database: http://bugzilla.xfce.org/show_bug.cgi?id=4542

Comment 9

[Joshua Cranmer [:jcranmer]]

(In reply to comment #7)
> (In reply to comment #4)
> > In any case, I was unable to reproduce with TB 2.0.0.17 using Fluxbox on a
> > Debian testing installation.
> 
> Can you reproduce the case for comment #6 in Fluxbox?

Kind of...

Desktop 2 = Firefox
Desktop 4 = Thunderbird

Open link in Firefox-> try to send, password dialog in desktop 2. Closed.
Write button in Thunderbird -> try to send, password dialog in desktop 4. Closed.

Open link in Firefox again -> window appeared in desktop 4. Closed.
Open link in Firefox yet again -> window appeared in desktop 4. Closed.

From what I recall of the compose window, we cache the compose window object, which is causing desktop stuff to be messed up. The issue that I see is not similar enough for me to feel comfortable confirming, but it is almost definitely limited to a compose window issue. Moving to Message Compose Window.

Comment 10

[Phil Ringnalda (:philor)]

You can tell whether you're seeing recycling problems by setting mail.compose.max_recycled_windows to 0 (or, work around it by just leaving it there: on modern hardware with modern XUL fastload, I don't actually see an difference in compose window opening speed from recycling, which I think was the purpose).

Comment 11

[Wayne Mery (:wsmwk)]

dupe of, or dependent on bug 388242?