942610 - Reply Window Loses Focus during typing and typed characters is sent to non-front-most window, when focus is stolen by main window or toaster popups (new message alert)

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[KitchM]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release)
Build ID: 20131030131730

Steps to reproduce:

Selected Reply or Reply All


Actual results:

After an undefined amount of time, the focus is lost and the cursor no longer appears and the key strokes appear to be affecting the main window in the background.


Expected results:

Compose window should stay active until selection of another window.

Comment 2

[Sander Goudswaard]

I am seeing similar behavior in 24.3.0 on Windows 8.1. However 'undefined amount of time' is in this case: when a new message arrives. If this happens while typing in a separate compose/reply window, the focus is set to the main window. Then, all characters typed are interpreted as commands, such as move, delete etc. which may ultimately cause data loss as explained in bug 957305.

Comment 3

[Michael Pope]

I also have this problem using 24.4.0 on Debian 7.2. I re-enact the problem by quickly hitting Ctrl+n about 10 times and some of the new compose/write windows are affected by the lose of focus and some are not.

Comment 4

[Edward Henigin]

I have this same problem, Thunderbird 24.4.0 on Windows 7 professional 64-bit. Mailbox mayhem ensues when the main windows steals focus from a compose window in which I'm typing.

Is anyone aware of any workarounds?

Comment 5

[WADA:World Anti-bad-Duping Agency]

(In reply to Sander Goudswaard from comment #2)
> However 'undefined amount of time' is in this case: when a new message arrives.
> If this happens while typing in a separate compose/reply window, the focus is set to the main window.
> Then, all characters typed are interpreted as commands, such as move, delete etc. 
> which may ultimately cause data loss as explained in bug 957305.

Bug 458570(and his dips), bug 948082 etc. is issue in Drag&Drop upon similar situation.
Setting dependecy of Drag case to this bug for ease of anlysis, tracking, search.

Comment 6

[WADA:World Anti-bad-Duping Agency]

Key event case is easiear to understand or imagine than Drag case.
    A people is typing with compose window open. key presss is executed in this sequence :
         a -> b -> c  ->d         -> e -> f -> g ...
                                      A
                                      |
                                     +---  Seconnd people clicks using mouse at messenger window
        => Because focus is moved to messenger window from composer window,
              key event from "e" is passed to messenger window, as designed.
New mail alert(toaster popup) steels focus by generating click event like one at messenger window?
Upon close of New mail alert(toaster popup),  New mail alert changes focused window to messenger window regardless of focused window when New mail alert(toaster popup) was shown?

Comment 7

[peterj]

In my case, the move of focus from the compose window to the main window always occurs shortly after starting typing. Usually with 5 to 10 characters, depending on how fast I am typing.

It happens multiple times every day. It has been happening for at least 6 months. 

TB 24.6.0  W7 64 bit

1 Extension: Folder Pane View Switcher 1.10

I will be trying with this extension disabled and also in safe mode.

Comment 8

[WADA:World Anti-bad-Duping Agency]

Unable to reproduce by "new mail notification of IMAP Inbox"(toaster popup) on Win.
1. At Thunderbitd :
    Disable CONDSTORE support(mail.server.default.use_condstore=false) to avoid bug Bug 885220.
    Enable IDLE command use. Enable new mail alert.
    Go Work Offline, Go Work Online, Click Inbox.
    Open composer window, type "abcdef", move cursor between "c" and "d".
2. At SeaMonkey, copy an Unread mail to Inbox of the IMAP account
3. Before new mail alert, click titlebar of composer window, and move focus to compose window.
4. After a while, new mail alert(toaster popup) is shown, and is closed.
5. Press "x" key => "x" is inserted between "c" and "d" at composer window.

Following is needed to see problem?
  Top window : composer window
  2d window : messenger window
  3rd or lower window : SeaMonkey
Many typed characters is needed when new mail alert is shown? (New mail shoud be copied at different PC)

Comment 9

[peterj]

(In reply to peterj from comment #7)
> In my case, the move of focus from the compose window to the main window
> always occurs shortly after starting typing. Usually with 5 to 10
> characters, depending on how fast I am typing.
> 
> It happens multiple times every day. It has been happening for at least 6
> months. 
> 
> TB 24.6.0  W7 64 bit
> 
> 1 Extension: Folder Pane View Switcher 1.10
> 
> I will be trying with this extension disabled and also in safe mode.


Disabling the extension and operating in safe mode does not eliminate the problem.

It seems to reduce the frequency, but since this is one of those "once or twice a day" events, it is really hard to judge accurately. Certainly there have been times when the composer window has been opened and then, after a short delay, the cpu usage soars and focus switches to the main window. 

Sometimes it seems to revert back. Other times, focus remains on the main window.

I keep forgetting to look at the logs just after it happens.

Comment 10

[peterj]

It occurs to me that as the main window and compose window are separate Windows tasks, the problem might not be in Thunderbird at all.

It could easily be in Windows, switching tasks for some reason.

I am not sure why or what, but worth throwing that observation into the pot.

I have long suspected Windows security as being related to the heavy CPU use that happens randomly in general. Perhaps accessing the file system triggers something that causes the heavy usage and/or the focus switch.

Comment 11

[peterj]

Safe mode does not stop the problem, but working offline does resolve it.

I believe it is IMAP related.

Comment 12

[mmolle]

This affects me, too, on Thunderbird 31.0 on Xubuntu 14.04 i386.

Comment 13

[peterj]

In my case, going to gmail (the IMAP account linked to TB) and unchecking "Show in IMAP" (under Labels) for some of the larger mailboxes has resolved the problem.

It doesn't mean there isn't a bug that causes the focus to change while TB is busy communicating with the IMAP server, but it no longer happens.

YMMV

Comment 15

[stu]

ubuntu 14.04.1
thunderbird 31.4.0

I hit control-n and the new message window pops up.
the focus remains on the main window so I start typing, and messages get deleted and archived and junked and all sorts of annoying things, that ctrl-z doesn't undo.

Clicking on the new window doesn't always get the focus there either.
Sometimes I have to close the new window and create another one and be careful to note where the focus is before I start typing.

Sometimes this happens with ctrl-r for reply as well.
The new window pops up, I start typing and make a mess of my inbox.

Comment 16

[Harald Oehlmann]

I can confirm under the following circumstances:
- Thunderbird 38.0.1
- Windows 8.1 64 bit
- IMAP folder with over 4000 messages in the inbox

Observation:
- Push the "Reply" button on an E-Mail
- Start typing the text
- After around 5 characters typed, the application goes into wait state
- Any further typed characters are seen as keyboard commands on the main Thunderbird window
- The window is normally not switched to the Thunderbird main window, only some functions invoked by the key presses may cause that
- Typing is practically only possible, if the Thunderbird main window is iconified

Workaround:
- Delete messages from the inbox to have not more than 3000 messages contained
- It seams that the focus is still switched, but this is so quick that you don't mention it any more.

Comment 17

[Harald Oehlmann]

About my upper post:
The workaround actually does not help to much.

It accumulates with running time. Restarting Thunderbird cures the issue for around one hour.

Still strange...

Comment 18

[mracz]

This is confirmed on Linux Mint 17.2 Cinnamon with TB 38.1.0

Can not create new message or reply to a message unless the opening message window is saved as draft. All keystrokes will be passed over to the main window beyond the new message window. Cursor can neither be placed to recipient fields nor to message pane. Clicking there just does nothing.

For me nothing helps to prevent this situation. The issue is independent of the size of IMAP folder.

However, after saving message as draft cursor appears and everything works as normal. 

Seems that a new window must appear to bring back things to normal. When saving the message a new window is opened for a second and that resolves the issue. So that I put my penny that this is a window management issue.

Indeed, very, very annoying.

Comment 19

[Harald Oehlmann]

Thunderbird 38.2.0 apparently fixes the issues.
At least no issues for 2 hours !

Congratulations,
Harald

Comment 20

[KitchM]

Where would a person get that version?  I have the latest from Ubuntu and it is 31.8.0.

Comment 21

[Quentin Wildhagen]

I am running TB 38.2.0 on Windows 10 Pro box, and this issue is a real problem.

When I click Reply, I normally immediately start typing my message, but Thunderbird has changed focus back to the main window and I am moving, tagging, and opening messages with every keystroke.
When I click forward, I start typing the address of the recipient, and it works up until the @, at which point the message window grays out for a second, and the focus goes back to the main window, lather, rinse repeat.

My mail is hosted by gMail, and I do have a rather large inbox (>1000 messages).

Comment 22

[Harald Oehlmann]

Sorry, was not cured by 38.2.0.
It is still crucial to close the main window when writing E-Mails...

Indeed, quite annoying, sorry...

There is just "something going on". I suppose, Thunderbird is doing something on IMAP to get address lists or save draft versions or whatever...

Comment 23

[mracz]

Problem is not solved on Linux Mint Cinnamon 17.2 with TB 38.2.0

Either a process is grabbing the cursor to the main window behind message window and the process is not timing out or this is a window management issue. Or both.

Anyway, clicking on 'Save as draft' turns things back to normal. Annoying.

Comment 24

[WADA:World Anti-bad-Duping Agency]

If ordinal focus switch between composer window, key event is normally passed to currently focused window.
1. At Composer : Type ABC, cursor is placed fter "C".
2, At main window, click Quick Search field.
   => focus is moved to Quick Search field of main window,
      and main window becomes Active Window(top most window at OS level), 
   Type "pqr" => pqr is placed in Quick Search field of main window, cursor is plaaced after "r"
3. Minimize main window, or click title bat of Composer window
   => Composer becomes Active Window(top most window at OS level)
   Type "def" => def is placed after "abc" at Composer Window.

=> Even when focus of cCmposer window is stolen by "click at main window", composing is normally resumed at Composer window when Composer window becomes Active Window(top most window at OS level) again.

To all problem reporters :

When your problem occurs:
  Which window is Active Window(top most window at OS level)?
  When you continued key pressing, where does the pressed key go?
  Which window's which field is actually focussed when Composer window looses focus by unknown event?
  What kind of event is trigger of "composer window looses focus"?

Comment 25

[Harald Oehlmann]

Thank you for the questions.

> When your problem occurs:
>  Which window is Active Window(top most window at OS level)?

Composer Window (new E-Mail)

>  When you continued key pressing, where does the pressed key go?

Thunderbird main window

>  Which window's which field is actually focussed when Composer window looses focus by unknown event?

It happens on any field. At the beginning it is the address field but it also happens with the message body or subject field

>  What kind of event is trigger of "composer window looses focus"?

I don't know. I can not verify that it is linked to the toaster "new mail" message.

It seams to me that thunderbird:
1) switches internally focus to main window (but without drawing, composer stays phisically in front)
2) does something for 5 seconds
3) switches back to composer window
4) then, any keys pressed in 2) are executed on the main window which may cause it to get focus, open new mail, whatever the key-binding does
5) any key pressed in 1) or 3) are directed to the composer window. E.g. there are keys missing...

It happens periodically each 10 seconds for me.  The pause is around 5 seconds.
It takes an hour to activate. Restarting Thunderbird cures the issue for an hour.

I use imap with a considerable amount of E-Mails and folders (100 folders, 5000 mails).
The server is a local high speed Linux Postfix/cyrrus Imap.
Thunderbird runs on Windows 8.1 64 bit.

My personal "workaround":
I minimize the Thunderbird main window so typed keys come to the composer key after the 5 seconds stall has elapsed. There is no missing characters but the 5 seconds stall each 10 seconds is still anoying.

Thank you,
Harald

Comment 26

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #25)

Thanks for quick explanation of phenomenon.

> When your problem occurs:
>  Which window is Active Window(top most window at OS level)?
Composer Window (new E-Mail)
>  When you continued key pressing, where does the pressed key go?
Thunderbird main window

When both window is overwrapped, Composer window is still top level window even after focus is internally moved to main window?
>          +------------------+
>          |                  |
>          | main window      |
>          | (newly focussed) |
>   +----------+              |
>   |          |--------------+
>   | composer |
>   |          | <== losed focus, but still top lebel window at OS level
>   +----------+
  
How did you know that main window is focused?

Comment 27

[KitchM]

I have just update to 38.2.0.  
Q. Which window is Active Window(top most window at OS level)?
A. I don't know what is meant by "at OS level, but the compose window is the topmost window.
Q. When you continued key pressing, where does the pressed key go?
A. To the main window underneath.
Q. Which window's which field is actually focussed when Composer window looses focus by unknown event?
A. Cannot tell since it is in the background at that point.  Focused window should have come to the top, but does not.
Q. What kind of event is trigger of "composer window looses focus"?
A. Good typists type fairly rapidly.  Therefore too many things have happened underneath and out of view before the problem has been noticed.  This makes this problem extremely annoying, especially when messages may be moved or deleted without intent.

I should also point out that once this problem starts in TB, the restarting of TB only allows one compose to be completed before it starts happening again.  There is no way around this behaviour that I can figure once it starts.

Do not forget that the selection of a link in a message often fails to bring the opened link in Firefox to the foreground, as well.  This also appears to be a focus problem, requiring the appropriate program to be restarted.

Comment 28

[mracz]

(In reply to WADA from comment #26)
> (In reply to Harald Oehlmann from comment #25)
> 
> Thanks for quick explanation of phenomenon.
> 
> > When your problem occurs:
> >  Which window is Active Window(top most window at OS level)?
> Composer Window (new E-Mail)
> >  When you continued key pressing, where does the pressed key go?
> Thunderbird main window
> 
> When both window is overwrapped, Composer window is still top level window
> even after focus is internally moved to main window?
> >          +------------------+
> >          |                  |
> >          | main window      |
> >          | (newly focussed) |
> >   +----------+              |
> >   |          |--------------+
> >   | composer |
> >   |          | <== losed focus, but still top lebel window at OS level
> >   +----------+
>   
> How did you know that main window is focused?

Composer window is top level window, and I understand that main window is focused because keystrokes are caught in main window e.g. pressing "N" will step next message in main window.

Comment 29

[WADA:World Anti-bad-Duping Agency]

Similar to "modal dialog happens at main window while composing"?
1. While typing at composer, modal dialog happens at main window due to some kind of event
2. modal dialog is shown as topmost window and is focused
3. click OK or Cancel at modal dialog
   => modal dialog as top most window is closed
   => focus is returned to main window(owner of the modal dialog)
In this case, I think composer is still shown as top most window in Desktop by current Tb.

If this kind of phenomenon, I think focus should be moved to main window.
If this kind of phenomenon, problem is :
   Newly focused window(main window) is not shown as topmost window(front window) even after focus switch.

Comment 30

[Harald Oehlmann]

Just add some additions:
I suppose the issue is that Thunderbird makes pauses (e.g. does something blocking) periodically each 10 seconds for 5 seconds. This is like a heartbeat. The pause time increases with the execution time ( 5 seconds after 1 hour).

The focus change is just a side effect. Normally the change is so quick that nothing is lost or redirected.
But with the upper periodic pause, the focus change gets noticeable.

Things I use:
- IMAP
- spell checker

The effect is still there when I disable all extensions.

So the issue is to find the reason for the delay.
Which function pauses with increasing time...

Comment 31

[WADA:World Anti-bad-Duping Agency]

To all problem reporters:
If Tb's main window is minmized while you are composing mail, can you see your problem?
If problem still can be observed, does frequency of problem decline?

Comment 32

[WADA:World Anti-bad-Duping Agency]

Drag&Drop is irrelevant to this bug, so move bug 458570 and bug 948082(report for Drag&Drop case) from dependency tree of this bug to "see also".

Comment 33

[Harald Oehlmann]

> To all problem reporters:
> If Tb's main window is minmized while you are composing mail, can you see your problem?
> If problem still can be observed, does frequency of problem decline?

The problem that keystrokes are sent to the main window does not appear any more.
The 5 seconds pause each 10 seconds is still there. It is in all TB and also on the main window when not composing any mail.

THank you,
Harald

Comment 34

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #33)
> > To all problem reporters:
> > > If Tb's main window is minmized while you are composing mail, can you see your problem?
> > If problem still can be observed, does frequency of problem decline?
> The problem that keystrokes are sent to the main window does not appear any more.

You looks to be able to observe problem pretty frequently and pretty easily :-)
Thanks for quick check.

Additional question to understand phenomenon correctly.
1. Start composing with "Tb's main window is visible". Composer is front most window.
   Some unread mails exists in folder which is selected at Tb's main window, 
2. Quickly type many characters(N...N is perhaps convenient, Don't type D).
3. If problem occurs, an unread mail is selected at Thread pane of main window by keystroke of "N".

After step 3, is focus moved back to composer window when you do typing only? (never do mouse operation etc.)
Or "click of composer window" is needed to continue mail composition?

Comment 35

[Harald Oehlmann]

> After step 3, is focus moved back to composer window when you do typing only? (never do mouse operation etc.)
> Or "click of composer window" is needed to continue mail composition?

No click needed. On the visible side, the composer window is never put to back and back to front.
Only the keystroks:
- are lost in the composer window
- act in the main window

For example, the enter key opens the corrent mail in a new tab, which often happens.

Thank you,
Harald

Comment 36

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #35)
> > After step 3, is focus moved back to composer window when you do typing only? (never do mouse operation etc.)
> > Or "click of composer window" is needed to continue mail composition?
> No click needed. On the visible side, the composer window is never put to
> back and back to front.
> Only the keystroks:
> - are lost in the composer window
> - act in the main window
> For example, the enter key opens the corrent mail in a new tab, which often happens.

It sounds that any keystoroke goes to main window forever after this bug occurs.
If so, how did you continue/resume to input text to composed mail by pressing keyboard?

Comment 37

[Harald Oehlmann]

> It sounds that any keystoroke goes to main window forever after this bug occurs.
> If so, how did you continue/resume to input text to composed mail by pressing keyboard?

The phenomenon lasts for 5 seconds.
Then it comes automatically back.

Comment 38

[mracz]

(In reply to WADA from comment #36)
> (In reply to Harald Oehlmann from comment #35)
> > > After step 3, is focus moved back to composer window when you do typing only? (never do mouse operation etc.)
> > > Or "click of composer window" is needed to continue mail composition?
> > No click needed. On the visible side, the composer window is never put to
> > back and back to front.
> > Only the keystroks:
> > - are lost in the composer window
> > - act in the main window
> > For example, the enter key opens the corrent mail in a new tab, which often happens.
> 
> It sounds that any keystoroke goes to main window forever after this bug
> occurs.
> If so, how did you continue/resume to input text to composed mail by
> pressing keyboard?

Here (Linux Mint Cinnamon) I can resume working on the compose window if I save a draft of the message. This makes a small window flash up for a moment, as message draft is saved and then everything returns to normal (I can click and type in compose window as usual) until I open a new message window again. There the issue starts again (clicking into the top level window where I would compose message does not do anything and all keystrokes are grabbed by main window behind).

Comment 39

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #37)
> The phenomenon lasts for 5 seconds.
> Then it comes automatically back.

I see. Thanks for answer. 
I now can understand your description about phenomenon written in comment #25.

To analyze this kind of problem, following is needed;
(1) Hook focus event at composer window and at main window, in order to know when focus is removed from composer window and moved back to compose window. This is relatively easily be achieved by addon for testing;
   addEventListner(focus event for this bug) at composer window and main window,
   and write event log to Error Console.
(2) After it, check what happens around "focus move from composer window to main window", what is executed at main window for 5 seconds while main window steels focus, who gets back focus to composer window after 5 seconds.

I have addon for acton like (1), but it takes time to modify my addon for analysis of this bug.
See log data attached to bug 948082 fo Drag&Drop event tracing log by my addon, please.

Comment 40

[WADA:World Anti-bad-Duping Agency]

To all problem reporters:
I modified my addon for test. Now focus event at composer window(s) and messenger window(s) is saved in JavaScript object and is dumped to Error Console when tracing is stopped.
Please see following web documents of my site.
  http://www.h2.dion.ne.jp/~radon/mozilla/tb-addon/WinBackMyTrash-0-1-0.html
  http://www.h2.dion.ne.jp/~radon/mozilla/tb-addon/WinBackMyTrash-0-1-0-EventTrace.html
This function merely logs only focus event at messenger window and composer window. Logic is pretty simple: Simply do window.addEventListener for focus event only at each window, and event listener simply saves event data in singleton. event.type and event.target.id only is currently logged.
So this is helpful only for first trouble shooting of this bug.

Comment 41

[Harald Oehlmann]

Thank you. Looks huge. The extension and buttons are installed.
I did not figure out how to open the error console.
And a more concrete test description would be helpful.

I can report additional observations:
   *   The focus issue also arises with the Lightning popup "New Appontment"
   *   The last two times, focus was not switched back to Composer/New appointment widget

Thank you,
Harald

Comment 42

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #41)
> I did not figure out how to open the error console.

Tools/Error Console.

> And a more concrete test description would be helpful.

Have you read pointed document? My add on has many menus/functions, but function for this bug is Button-3/Start or Stop FocusEvent only...

Comment 43

[Harald Oehlmann]

Here are the two event traces:

2015/08/31 17:20:22.548 GMT messenger#1 : Button_3,click#=2,req=2120,label=Stop Event Trace,winType=messenger
Logging for FocusEvent is started.
TimeStamp=2015/08/31 17:17:44.401 GMT, window=messengercompose#1, event.type=focus, target.nodeName=#document
TimeStamp=2015/08/31 17:17:44.402 GMT, window=messengercompose#1, event.type=focus
TimeStamp=2015/08/31 17:18:26.736 GMT, window=messengercompose#1, event.type=focus, target.nodeName=#document
TimeStamp=2015/08/31 17:18:26.737 GMT, window=messengercompose#1, event.type=focus
TimeStamp=2015/08/31 17:19:36.176 GMT, window=messengercompose#1, event.type=focus, target.nodeName=#document
TimeStamp=2015/08/31 17:19:36.177 GMT, window=messengercompose#1, event.type=focus
TimeStamp=2015/08/31 17:20:06.568 GMT, window=messenger#1, event.type=focus, target.nodeName=#document
TimeStamp=2015/08/31 17:20:06.569 GMT, window=messenger#1, event.type=focus
TimeStamp=2015/08/31 17:20:06.570 GMT, window=messenger#1, event.type=focus, target.nodeName=A

2015/08/31 17:20:22.528 GMT messenger#1 : Button_3,click#=2,req=2120,label=Stop Event Trace,winType=messenger
Invoked from menu.
  tag = menuitem
  id = WinBackMyTrash_3_EventTrace_6
  value = 2120
  label = Stop Event Trace

Thank you,
Harald

Comment 44

[WADA:World Anti-bad-Duping Agency]

(In reply to Harald Oehlmann from comment #43)
> TimeStamp=2015/08/31 17:19:36.176 GMT, window=messengercompose#1, event.type=focus, target.nodeName=#document
> TimeStamp=2015/08/31 17:19:36.177 GMT, window=messengercompose#1, event.type=focus
> TimeStamp=2015/08/31 17:20:06.568 GMT, window=messenger#1, event.type=focus, target.nodeName=#document
> TimeStamp=2015/08/31 17:20:06.569 GMT, window=messenger#1, event.type=focus
> TimeStamp=2015/08/31 17:20:06.570 GMT, window=messenger#1, event.type=focus, target.nodeName=A

This log : focus event occurred in composer window at 17:19:36,
           then focus event occurred in messenger window at 17:20:06.
You could reproduce your problem at 2015/08/31 17:20:22?

Comment 45

[WADA:World Anti-bad-Duping Agency]

To problem reporters:
Do you enable auto-save f draft? What is your auto-save interval?
If you show "confirmation dialog after draft save" (Copies&Folders of each Identity),
when you saw your problem, do you see the "dialog after draft save"?

Comment 46

[WADA:World Anti-bad-Duping Agency]

FYI.
A way to know "what Thunderbird is doing" is "Getting Process Monitor log for Tb's file I/O".
  e.g. If message folder open, xxx.msf file is opened aand read.
       If message folder data access, data in xxx(no .msf) is reaad or written.
       If prefs.js update, data is written to prefs.js.
1. Open messenger window and composer window, Start EventTrace for Focus Event.
   Continue mail composition.
2. When you feel that problem will be reproduced, start Process Monitor if MS Windows.
     See https://technet.microsoft.com/en-us/sysinternals/bb896645
     Filter = process name is thunderbird.exe, Include.
3. When problem is reproduced, 
   Terminate Process Monitor, save log data to file. stop EventTrace for Focus event.
4. "Timestamp in GMT when focus steel happened" is known by EventTrace log.
   Check Process Monitor log(timestamp = local time) around the timestamp.
Note: Many free Tool like "Process Monitor on Win" is available for Linux and Mac OS X.

Comment 47

[KitchM]

To help us all follow along, please explain:
A. "Getting Process Monitor log..."
B.  "messenger window"
C. Recommended tool for  Linux.

Thanks.

Comment 48

[WADA:World Anti-bad-Duping Agency]

(In reply to KitchM from comment #47)
> A. "Getting Process Monitor log..."

Have you read pointed document?

> B.  "messenger window"

Internal name of window. String in documentURI,
You can see it via "JavaScript Object of top level #document element" using DOM Inspector addon.
  main window : documentURI = chrome://messenger/content/messenger.xul
  composer    : documentURI = chrome://messenger/content/messengercompose/messengercompose.xul
My EventTrace shows string in this documentURI as window name.

> C. Recommended tool for  Linux.

Do Google Search by yourself, please. I'm Windows user.

Comment 49

[KitchM]

I am hoping that my original problem will be addressed, since it is on a Linux platform.  Thank you.

Comment 50

[WADA:World Anti-bad-Duping Agency]

(In reply to KitchM from comment #49)

Google search sample, search for words of "linux tool monitor file i/o".
https://www.google.com/?gws_rd=ssl#q=linux+tool+monitor+file+i%2Fo

Comment 51

[WADA:World Anti-bad-Duping Agency]

I met bug 460238. "focus steeling by elevator popup" case may br that bug.
Setting dependency.

Comment 52

[Mark Aitchison]

Further to Comment 15, the same thing (loose focus AND unable to regain focus by clicking on window) still happens with Thunderbird 38.5.1 under Kubuntu 14.04; seems to happen for any new reply window until I restart Thunderbird. Quite serious... all manner of unwanted things happen to messages, only some of which I can undo.

Comment 53

[KitchM]

Am now using 38.5.1 on 14.04 Xubuntu.  Problem has not appeared recently.

It should be noted that this is not an IMAP problem, as I do not use that.

Comment 54

[Matt]

Recently someone came to SUMO with this issue on Windows 10...  In that case turning off the Windows theme sideshow fixed the issue.  While looking for this bug. I noticed Bug 1234317 which also appears to be dealing with a similar issue in Firefox.

But reading through this Bug report I am not clear,  is this a Linux only issue that has drawn Windows comments. (Such as mine)  Or is this a multi platform issue?.

Comment 55

[Harald Oehlmann]

Is Multi-PLatform. Also on Win 10, No Sideview, nothing.
Thunderbird often Pauses for 10 seconds.
I have: IMAP, EnigmaMail.

Comment 56

[Lynn (D)]

I'm seeing this with regularity on 38.5.1 under Windows 10 Pro.  All it takes is to bring up a new compose window (either new message or a reply) and hit the Caps Lock key.  Focus immediately goes back to the main window which then starts eating my keystrokes decimating my mail folders as others have observed.

It doesn't matter if I'm going into or out of Caps Lock, every tap of that key bounces focus around and rarely lands it back on the Compose window.

Comment 57

[Lynn (D)]

(In reply to Lynn (D) from comment #56)
More information:  I'm on a Dell XPS laptop and noticed that the focus shadow on ANY window flashes barely noticeable when the Caps Lock key is hit.  Further searching for solutions pointed out Dell's Quickset utility.  I killed it in Task Manager and Caps Lock no longer changes focus anywhere and Thunderbird's compose window works just fine now.

Thunderbird's focus still lands wrong if anything momentarily interrupts focus, but at least my Caps Lock key no longer triggers it.

(Now to figure out how to keep QuickSet from coming back after my next reboot)

Comment 58

[pascal]

exactly same problem here. a fix would be very, very nice.

Comment 59

[Wayne Mery (:wsmwk)]

(In reply to KitchM from comment #53)
> Am now using 38.5.1 on 14.04 Xubuntu.  Problem has not appeared recently.

since 4-6 months perhaps?

Comment 60

[Wayne Mery (:wsmwk)]

Matt, I think windows 10 issues deserve their own bug. Whether that's 1234317 or some other bug.

ref:
https://support.mozilla.org/en-US/questions/1106260 
https://support.mozilla.org/en-US/questions/1097361

Comment 61

[NathanT]

I have experienced this focus-switching problem for about the last 8 months using Thunderbird / Lightning on Windows 7.  Inbox generally contains < 20 messages, as I archive messages I'm done with.  In my case, the Lightning calendar seems to be what causes the delays (and therefore the noticeable focus switch time and the annoying main screen hot-key mayhem when keypresses get routed to the main window).  

If I disable Lightning, I see no noticeable delays.  The delay may well be the fact that I've got a total of 8 calendars syncing to two different CalDav servers.  I notice no significant delays on other Windows Vista boxes running Thunderbird + Lightning with 1-2 calendars from 1 CalDav server.

However, regardless of the source of the delays where the UI thread freezes, the fact that the main window grabs focus (or at least becomes the receiver of keypresses) seems like a bug.

Comment 62

[Mark Foley]

I am currently also having these same problems: compose window focus-shift and typing delay. Using Thunderbird 38.5.1, Lightning 4.0.5.2 on Windows 7. Lightning is the only add-on. Server is IMAP, self-hosted (Linux/Dovecot). The problem is serious enough that our office will likely switch away from using Thunderbird if there is no solution; users getting grumpy. The original posting of this bug was November, 2013 ...

Comment 63

[Mark Aitchison]

(In reply to Mark Foley from comment #62)
> I am currently also having these same problems...
> original posting of this bug was November, 2013 ...

From a comment in bug report 1185818 (seems to be same as this bug) the link to the Dec 2012 comments: https://www.kubuntuforums.net/showthread.php?63836-Keystrokes-sent-to-window-without-focus-in-Firefox-Thunderbird it seems:
1) to be older even than Nov 2013
2) it affects firefox as well as thunderbird (I might have experienced it when saving files in firefox)
3) the last comment: "It seems like this is a conflict with unclutter. Either disabling unclutter, or using the `-noevents ` option is a valid workaround" might be helpful.

That kubuntu forum comment back in 2012 made it sound like it might be kubuntu-specific; well people have been reporting it on Windows, etc... but I use Kubuntu too, so I wonder is it more frequently found in some systems, or even never found in some other configurations? Anyone here using two different linuxes and never seeing it on one, for example??

Comment 64

[Harald Oehlmann]

As the delay only appears in combination with lightning for some people (including me), I have added a bug into the calender tracker:

https://bugzilla.mozilla.org/show_bug.cgi?id=1247178

We have two bugs:
   *   Thunderbird pauses for 30 seconds when run for more that 4 hours
   *   In the composer window, the focus is switched back to the main window and keystrokes may be executed there. Then it is switched back.

The bugs are dependent, as you can only notice the focus bug in combination with the delay. Otherwise it is probably to quick to be noticed.

I use Windows 10 64 bit GER and Thunderbird 38.5.1 32 bit and Lightning 4.0.5.2. I also use Enigmail 1.8.2 but this seams to be harmless....

Thank you all,
Harald

Comment 65

[Kent James (:rkent)]

One possible way forward with this would be to put together a simple extension that adds an onblur listener to the composer window, and dumps the stack that causes the loss of focus to the error console, where it could be grabbed and posted here by people who are seeing this bug.

I'm not sure if I'll be able to get to that myself in the near future, but I'll Need Info myself to check back at some point to see if I can do that. Anyone else with appropriate skills is welcome to try that as well.

Comment 66

[KitchM]

Just happened again!  Hadn't seen it in a long time, but there it is again.

I am now using Xubuntu 14.04 LTS and Thunderbird 38.6.0 (no Lightning).

Comment 67

[Alan]

I'm seeing this repeatedly.  Thunderbird 38.6 (no Lightning), Win 10.  In addition, even if Thunderbird does not have focus, it will occasionally temporarily "switch position" from one monitor to another.  I think it steals focus in this circumstance, but I'm not sure.

Comment 68

[Wayne Mery (:wsmwk)]

Windows 10 issues have resulted in more than usual number of reports in support forums. 
Unfortunately I don't have links.  But bug 1258152 is such a report.
bug 1121870 is win7 report

Comment 69

[KitchM]

Just happened a few days in a row now, so I must assume that the problem is back.  It does not matter if it is a fresh boot as it was this morning or many hours after boot as it was the other day.  Same specs as above.

Comment 70

[lorenzo]

Same problem with thunderbird on Debian linux.
I've noticed that it does not happen when I'm replying-to-all to a message in an IMAP folder. However if the message is in a local folder, hitting reply-to-all quite often loses focus.

Perhaps it's some sort of race condition that happens when the draft folder is on a (networked) IMAP folder..?

Comment 71

[KitchM]

See comment 53

Comment 72

[Alan]

Still present in 45.1.0.

Comment 73

[PetrOps]

STILL present in 45.1.0. Absolutely ridiculous. I can't use this in this f'd-up state. TB is just too buggy. Does anybody know a decent free alternative to TB?

Comment 74

[Alan]

Still present in 45.1.1.  I see nobody is yet assigned to this long-standing and truly annoying bug.  Is it getting any developer attention?

Comment 75

[KitchM]

Please hang in there everyone.  They know about this.  It is just too bad that there is no  time for this as coders move to other projects.  I believe it is a problem where there is a real shortage of help.

Please be sure to vote for this bug near the top of the page.

Maybe Mozilla will find a way for us to financially support this bug directly.

Thank you.

Comment 76

[Matt]

(In reply to KitchM from comment #75)

It is really off topic here to post messages that do not assist in the fixing of the resolution of the bug.  But this time I will risk the wrath of the powers that be.

> Please hang in there everyone.  They know about this.  It is just too bad
> that there is no  time for this as coders move to other projects.  I believe
> it is a problem where there is a real shortage of help.

Quite true,  lots to do and few volunteers.

> 
> Please be sure to vote for this bug near the top of the page.
> 
> Maybe Mozilla will find a way for us to financially support this bug
> directly.

This is what prompted me to reply here.  Mozilla and Thunderbird are basically two different organisations and as it stands now the contributions Mozilla make are small and getting smaller.  So should you be considering financial contributions,  please make them to Thunderbird.  See https://donate.mozilla.org/en-US/thunderbird/

Due to the fact we need funds for release management and infrastructure like server to test builds on.  We are not accepting directed donations as you suggest KitchM.  

While this and other bugs get attention because they are annoying,  we do not want to be in a situation where we can not keep the lights on, or patch security holes, but have loads of money tied up in directed donations that do not yet have enough donations to pay for the job.

So please donate,  but do not attempt to put money into a specific issue.  This bug has not been fully investigated to work out exactly what is the cause.  It may be that it turns out to be relatively minor.  Alternatively it could be something fundamental in the XUL user interface definition that could cost ten of Thousands to fix.  But it may well be it takes someone a week to define the cause.

Comment 77

[KitchM]

Thanks, Matt.

Here's hoping that there will be a way to concentrate funding on the most desired or most profitable bugs.

Comment 78

[pascal]

yep let's hope. so fuckiong boring bug :(

Comment 79

[KitchM]

Still present in 38.8.0 in Xubuntu  14.04.  I tried to forward an e-mail and it lost focus on front window again.

Comment 80

[Matt]

(In reply to KitchM from comment #79)
> Still present in 38.8.0 in Xubuntu  14.04.  I tried to forward an e-mail and
> it lost focus on front window again.

See up the top where it says Status:NEW 
Until that changes, further posting to this bug simply stating it has not been fixed will muddy the waters to actually fixing the bug. When someone comes to fix the bug it takes ages just to work out what is the actual bug report and what is chaff that is wasting the developers time reading it to toss it aside as not contributing to the fixing of the issue.  

As it is not Status: Fixed  then everyone know it remains open.  That is the whole point of the bug having a status.

Before posting again, evaluate what you have to say against these guidelines https://bugzilla.mozilla.org/page.cgi?id=etiquette.html and err on the side of caution.

Comment 81

[KitchM]

Sorry, Matt.  Didn't mean to offend you.  I must have missed where one keeps the information relevant by stating which version has the issue.  If I was a programmer, I would want to know that as one of the very first and most primary items of information.  In other words, (as people are so vociferous in pointing out) which version are you using and on what platform.  Since I don't use a "Branch" (I use a version), that can't be the correct place.  Right?  Besides, changing the version on the first post does nothing to let the experts know where the problem started; also important.

As to the over-simplified issue of using Fixed or Open, as most users know, problems which no longer show up on later versions or platforms will not be fixed, and for good reasons.  Please note that this problem has not existed on certain versions and platform combinations for me since the issue was opened.  So, no, that is not the whole purpose of bugs having a status, or that would be a silly usage of that notation.  Besides, this is not just for the programmers of TB, but rather for the community as a whole.

Actually, the real problem is obviously comments like yours which waste time and space.  Please refrain.  Thank you.

Others, please keep posting your latest version and platform if you find a later one with the problem.  (And nothing more!)  Any bozo will then be able to simply read the last post and know where we all stand.

Thank you all.

Comment 82

[George Hyman]

The problem seems to have gotten worse after I changed from Windows7/Thunderbird 44/imap to windows 10/Thunderbird 45.1.1/exquilla.  I also changed themes from Noia Fox to Dream of Waves.  I don't think the theme is particularly relevant, because I think I had the problem with the default theme as well.

Comment 83

[Wayne Mery (:wsmwk)]

(In reply to KitchM from comment #81)
> Sorry, Matt.  Didn't mean to offend you.  I must have missed where one keeps
> the information relevant by stating which version has the issue.  If I was a
> programmer, I would want to know that as one of the very first and most
> primary items of information.  In other words, (as people are so vociferous
> in pointing out) which version are you using and on what platform.  Since I
> don't use a "Branch" (I use a version), that can't be the correct place. 
> Right?  Besides, changing the version on the first post does nothing to let
> the experts know where the problem started; also important.

KitchM, releases come every 6 weeks. There is ABSOLUTELY no need for anyone to comment every 6 weeks that "this problem still exists". Even when a new user signs on the the bug report, it's pointless to comment and it's spam unless it also adds NEW knowledge or contributes toward getting a fix.  

If you are a user who only just started seeing this problem, see one of the other bugs under "See Also", or perhaps file a new bug report rather than sign on to an old bug.

Comment 84

[Wayne Mery (:wsmwk)]

(In reply to George Hyman from comment #82)
> The problem seems to have gotten worse after I changed from
> Windows7/Thunderbird 44/imap to windows 10/Thunderbird 45.1.1/exquilla. 

George, it's interesting that it got worse for you on win10.  Windows 10 is tracked in bug 1258152.

Is exquilla really a factor?  
In other words, if you are are able to disable exquilla, does the rate of occurence chnage?


> I also changed themes from Noia Fox to Dream of Waves.  I don't think the
> theme is particularly relevant, because I think I had the problem with the
> default theme as well.

I believe the themes previously discussed are Windows themes, not application themes :)

Comment 85

[Wayne Mery (:wsmwk)]

(In reply to Sander Goudswaard from comment #2)
> I am seeing similar behavior in 24.3.0 on Windows 8.1. However 'undefined
> amount of time' is in this case: when a new message arrives. If this happens
> while typing in a separate compose/reply window, the focus is set to the
> main window. Then, all characters typed are interpreted as commands, such as
> move, delete etc. which may ultimately cause data loss as explained in bug
> 957305.

Sander reported to me about a month ago that "I am not able to reproduce it anymore with the current version of Thunderbird and Windows 10.  ...  Perhaps the users who still experience this issue could benefit from using this tool to identify if the issue is caused by Thunderbird or by a [C# application] 3rd party app: http://www.darthcontinent.com/2014/02/focusmonitor-identifies-processes.html "

I haven't tested the app, and I'm not sure that will help.  

There is also NSPR logging which requires 3 modules to be enabled. But unfortunately I lost the reference after a windows hang. I hope Neil can suggest the proper modules and log level

Comment 86

[Neil Deakin]

This looks to be more like an OS-level focus issue. On Linux you can use nspr logging with WidgetFocus:5

On Windows, you would be better to log windows messages using spy++ or some similar tool.

Firefox focus issues can also be logged with Focus:5

Comment 87

[KitchM]

Wayne Merv, you are mistaken; hopefully no one is submitting every six weeks.  Rather, they are submitting when they find a different Version/OS combination, and/or when the problem goes away on a given combination.  This is most helpful, and it is indeed "New" knowledge.

Further, reason should show you that the six week cycle has absolutely nothing to do with this bug unless someone is actively making a change in a release that will affect this bug and they note it here.  We are not seeing that.

Also, creating new bugs about this issue actually does cause confusion.  I am hoping your unclear wording was not suggesting such.  No one should create a new bug about this issue.

Neil Deakin, looking this up did seem to indicate that it might apply.  Could you please explain how we non-programmers can check such logging?  I would like to try.  Anything to help nail this down.

Also, does your suggestion apply in a non-QT application or environment?

Thanks.

Comment 88

[George Hyman]

I'm putting the results of my investigations into 128152 since that's specific to win10.

Comment 89

[KitchM]

Sorry about this being somewhat off-topic, but does anyone know of a forum where work-arounds for this problem are discussed?  Feel free to private mail me.

Thanks all.

Comment 90

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 1291694 is for that "Focus of password dialog" is stolen by "Sending status/progress window".
It's similar phenomenon to this bug.

Comment 91

[KitchM]

Problem back for me on 45.2.0 on Xubuntu 14.04.4.

However, found workaround. Select reply again while leaving first reply compose window open.  Second compose window does not have the problem; only the first one.

Hope that helps.

Comment 92

[George Hyman]

Unfortunately, that workaround does not work on windows 10, at least for me.  To me, this indicates that this issue has at least something to do with building thunderbird for each environment according to each one's peculiarities/requirements.

Comment 93

[KitchM]

Interesting.  Which version are you using?

Comment 94

[George Hyman]

Latest Thunderbird - 45.2.0 Windows 10 build is controlled by corp IT not obvious which build.

Comment 95

[Harald Ommang]

Obviously something happened to keyboard focus in build 45.2.0. If I click on a new message, and hit Delete on the keyboard, nothing happens. I have to click twice on the message before keyboard works. Extremely annoying. This was OK before this build.

Comment 96

[greg.b.friedman]

This issue just started occuring for me in the last few months using Thunderbird 45.2 on Windows 7. It's definitely resulted in loss of data. Hard to believe this is a long-known issue but not getting any priority.

Comment 97

[Kent James (:rkent)]

I check back on this every so often to see if there is progress in reproducibility. I don't really see any, but I did not read all of the comments.

If you are experiencing this (I am not or only rarely) then you are on the critical path to fixing this bug. We really need reliable steps to reproduce.

If someone posts something that they say is reliable, and you care about this bug, then try to duplicate their steps, and see if you can reproduce (and report that here).

Comment 98

[Alan]

Hi Kent, I understand that reproducibility is desirable, but this is a very serious bug, and if it were easily reproducible the steps wd have been reported already.  (I say it is serious because it has been reported to cause data loss, which I have experienced as well.  It is additionally a persistant annoyance.)  In order to enhance reproducibility, I suspect code must be added that detects and records loss of window focus, especially for a composition window.  Please give the users who a plagued by this some way to proceed.  All we see is no progress (and indeed nobody assigned to this bug).  Thanks.

Comment 99

[greg.b.friedman]

Alan is precisely right. If I knew what circumstances cause this bug, I'd already be avoiding them. But I haven't noticed any patterns, and I certainly spend enough time typing mail messages in Thunderbird. The issue is unusual enough that it happens at most a couple of times a week, but that's already too much. If anyone wants to give me anything to run that will monitor Thunderbird's behavior, I'd be happy to provide the timestamps for when the bugs occur. Beyond that, I'm just an end user and not enough of an expert at all of the behaviors to know what to look out for. There's no way I'm figuring out how to duplicate the issue myself without some coaching from someone at Thunderbird or Mozilla who knows better.

Comment 100

[KitchM]

There are some additional symptoms to report.  It appears that the problem also afflicts Firefox.  If one opens the Bookmarks menu and selects “Show All Bookmarks” the new window opens.  One can then right-click to select the context menu while hovering over “Bookmarks Toolbar”, and then select “New Folder”.  As one begins to type, the focus is sometimes lost into the background window.

This behavior is exactly the same as in Thunderbird.  This would therefore indicate that the problem exists in other Mozilla products.

I hope this helps.

Comment 101

[Karl Tomlinson (:karlt)]

Running with NSPR_LOG_MODULES=WidgetFocus:5,Focus:5,timestamp in the environment will produce a log that may help identify whether the focus change is from within the app or from the OS.  Please indicate the time corresponding to the start to the problem, so that the relevant portion of the log can be identified.

Comment 102

[KitchM]

Karl, I would like to do that but I'm not sure how.  Could you please clearly define the steps to set this up, and then which log we might want to look at?

Thanks.

Comment 103

[Matt]

(In reply to KitchM from comment #102)
> Karl, I would like to do that but I'm not sure how.  Could you please
> clearly define the steps to set this up, and then which log we might want to
> look at?
> 
> Thanks.

See the information here https://wiki.mozilla.org/MailNews:Logging#Linux.2Funix

Comment 104

[KitchM]

How long does the logging go on?

Comment 105

[p_zeller]

While logging I lost focus on a new-message window which I just opened. Clicking on the window did not bring focus back. My System clock showed 11:01 when this happened (German time). Below is the relevant portion of the log (I don't want to upload the full log here, since it seems to contain some private information, but I can send it to anyone who wants to work on a fix): 

This is for Thunderbird 45.3.0 on Ubuntu 16.04 with the following extensions: Calendar Tweaks, Correct Identity, Enigmail, Exchange EWS Provider, Lightning, Messaging Menu and Unity Launcher integration, Provider for Google Calendar, Search Results Sort By Date Not Relevance

    2016-10-14 09:00:09.694183 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Lowered [Currently: 7f6bccc2a420 7f6b7f627820]
    2016-10-14 09:00:09.694193 UTC - [Main Thread]: D/Focus   Lowered Window: chrome://browser/content/browser.xul
    2016-10-14 09:00:09.694197 UTC - [Main Thread]: D/Focus   Active Window: chrome://browser/content/browser.xul
    2016-10-14 09:00:09.722406 UTC - [Main Thread]: D/Focus <<Blur begin>>
    2016-10-14 09:00:09.722435 UTC - [Main Thread]: D/Focus Element a has been blurred
    2016-10-14 09:00:28.692813 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Raised [Currently: 0 0]
    2016-10-14 09:00:28.692824 UTC - [Main Thread]: D/Focus   Raised Window: 7f6bccc2a420 chrome://browser/content/browser.xul
    2016-10-14 09:00:28.728182 UTC - [Main Thread]: D/Focus <<Focus begin>>
    2016-10-14 09:00:28.728214 UTC - [Main Thread]: D/Focus Element a has been focused
    2016-10-14 09:00:28.728218 UTC - [Main Thread]: D/Focus  from html
    2016-10-14 09:00:28.728220 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 1 Flags: 0]
    2016-10-14 09:00:28.730988 UTC - [Main Thread]: D/Focus Update Caret: 0 1
    2016-10-14 09:00:30.524975 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
    2016-10-14 09:00:30.527484 UTC - [Main Thread]: D/Focus Shift Focus: (none)
    2016-10-14 09:00:30.527490 UTC - [Main Thread]: D/Focus  Flags: 2 Current Window: 7f6b7f627820 New Window: 7f6ba75d0020 Current Element: 7f6bcf2eb3c0
    2016-10-14 09:00:30.527492 UTC - [Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 0 SendFocus: 1
    2016-10-14 09:00:30.527494 UTC - [Main Thread]: D/Focus <<Blur begin>>
    2016-10-14 09:00:30.527505 UTC - [Main Thread]: D/Focus Element a has been blurred
    2016-10-14 09:00:30.528242 UTC - [Main Thread]: D/Focus <<Focus begin>>
    2016-10-14 09:00:30.528251 UTC - [Main Thread]: D/Focus Element (none) has been focused
    2016-10-14 09:00:30.528253 UTC - [Main Thread]: D/Focus  from html
    2016-10-14 09:00:30.528255 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 0 Flags: 2]
    2016-10-14 09:00:30.529126 UTC - [Main Thread]: D/Focus Update Caret: 0 1
    2016-10-14 09:00:30.529132 UTC - [Main Thread]: D/Focus <<SetFocus end>>
    2016-10-14 09:00:34.093938 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Lowered [Currently: 7f6bccc2a420 7f6ba75d0020]
    2016-10-14 09:00:34.093947 UTC - [Main Thread]: D/Focus   Lowered Window: chrome://browser/content/browser.xul
    2016-10-14 09:00:34.093949 UTC - [Main Thread]: D/Focus   Active Window: chrome://browser/content/browser.xul
    2016-10-14 09:00:34.126164 UTC - [Main Thread]: D/Focus <<Blur begin>>
    2016-10-14 09:00:34.126176 UTC - [Main Thread]: D/Focus Element (none) has been blurred
    2016-10-14 09:01:55.247273 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Raised [Currently: 0 0]
    2016-10-14 09:01:55.247281 UTC - [Main Thread]: D/Focus   Raised Window: 7f6bccc2a420 chrome://browser/content/browser.xul
    2016-10-14 09:01:55.277622 UTC - [Main Thread]: D/Focus <<Focus begin>>
    2016-10-14 09:01:55.277639 UTC - [Main Thread]: D/Focus Element (none) has been focused
    2016-10-14 09:01:55.277642 UTC - [Main Thread]: D/Focus  from html
    2016-10-14 09:01:55.277644 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 1 Flags: 0]
    2016-10-14 09:01:55.278916 UTC - [Main Thread]: D/Focus Update Caret: 0 1
    2016-10-14 09:02:01.005073 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Lowered [Currently: 7f6bccc2a420 7f6ba75d0020]
    2016-10-14 09:02:01.005088 UTC - [Main Thread]: D/Focus   Lowered Window: chrome://browser/content/browser.xul
    2016-10-14 09:02:01.005093 UTC - [Main Thread]: D/Focus   Active Window: chrome://browser/content/browser.xul
    2016-10-14 09:02:01.030309 UTC - [Main Thread]: D/Focus <<Blur begin>>
    2016-10-14 09:02:01.030321 UTC - [Main Thread]: D/Focus Element (none) has been blurred
    2016-10-14 09:02:01.034625 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Raised [Currently: 0 0]
    2016-10-14 09:02:01.034630 UTC - [Main Thread]: D/Focus   Raised Window: 7f6bccc2a420 chrome://browser/content/browser.xul
    2016-10-14 09:02:01.057033 UTC - [Main Thread]: D/Focus <<Focus begin>>
    2016-10-14 09:02:01.057054 UTC - [Main Thread]: D/Focus Element (none) has been focused
    2016-10-14 09:02:01.057058 UTC - [Main Thread]: D/Focus  from html
    2016-10-14 09:02:01.057060 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 1 Flags: 0]
    2016-10-14 09:02:01.059672 UTC - [Main Thread]: D/Focus Update Caret: 0 1
    2016-10-14 09:02:01.121971 UTC - [Main Thread]: D/Focus Window 7f6bccc2a420 Lowered [Currently: 7f6bccc2a420 7f6ba75d0020]
    2016-10-14 09:02:01.121978 UTC - [Main Thread]: D/Focus   Lowered Window: chrome://browser/content/browser.xul
    2016-10-14 09:02:01.121979 UTC - [Main Thread]: D/Focus   Active Window: chrome://browser/content/browser.xul
    2016-10-14 09:02:01.190483 UTC - [Main Thread]: D/Focus <<Blur begin>>
    2016-10-14 09:02:01.190494 UTC - [Main Thread]: D/Focus Element (none) has been blurred

Comment 106

[p_zeller]

It happened again, here is the relevant part of the log:

2016-10-17 10:14:11.339259 UTC - [Main Thread]: D/Focus <<Focus begin>>
2016-10-17 10:14:11.339265 UTC - [Main Thread]: D/Focus Element (none) has been focused
2016-10-17 10:14:11.339267 UTC - [Main Thread]: D/Focus  from html
2016-10-17 10:14:11.339268 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 0 Raised: 0 Flags: 0]
2016-10-17 10:14:11.340031 UTC - [Main Thread]: D/Focus Update Caret: 0 1
2016-10-17 10:14:14.160645 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:14.160684 UTC - [Main Thread]: D/Focus Shift Focus: a
2016-10-17 10:14:14.160690 UTC - [Main Thread]: D/Focus  Flags: 1002 Current Window: 7fa03c998c20 New Window: 7fa03c998c20 Current Element: 0
2016-10-17 10:14:14.160694 UTC - [Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
2016-10-17 10:14:14.160697 UTC - [Main Thread]: D/Focus <<Blur begin>>
2016-10-17 10:14:14.160706 UTC - [Main Thread]: D/Focus Element (none) has been blurred
2016-10-17 10:14:14.160710 UTC - [Main Thread]: D/Focus Update Caret: 0 1
2016-10-17 10:14:14.160716 UTC - [Main Thread]: D/Focus <<Focus begin>>
2016-10-17 10:14:14.160721 UTC - [Main Thread]: D/Focus Element a has been focused
2016-10-17 10:14:14.160724 UTC - [Main Thread]: D/Focus  from html
2016-10-17 10:14:14.160770 UTC - [Main Thread]: D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 1002]
2016-10-17 10:14:14.163857 UTC - [Main Thread]: D/Focus Update Caret: 0 0
2016-10-17 10:14:14.163871 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:14.164373 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:14.164741 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:30.435960 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:30.435985 UTC - [Main Thread]: D/Focus Shift Focus: a
2016-10-17 10:14:30.435989 UTC - [Main Thread]: D/Focus  Flags: 1002 Current Window: 7fa03c998c20 New Window: 7fa03c998c20 Current Element: 0
2016-10-17 10:14:30.435991 UTC - [Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
2016-10-17 10:14:30.435992 UTC - [Main Thread]: D/Focus <<Blur begin>>
2016-10-17 10:14:30.436003 UTC - [Main Thread]: D/Focus Element (none) has been blurred
2016-10-17 10:14:30.436005 UTC - [Main Thread]: D/Focus Update Caret: 0 1
2016-10-17 10:14:30.436009 UTC - [Main Thread]: D/Focus <<Focus begin>>
2016-10-17 10:14:30.436012 UTC - [Main Thread]: D/Focus Element a has been focused
2016-10-17 10:14:30.436014 UTC - [Main Thread]: D/Focus  from html
2016-10-17 10:14:30.436016 UTC - [Main Thread]: D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 1002]
2016-10-17 10:14:30.438629 UTC - [Main Thread]: D/Focus Update Caret: 0 0
2016-10-17 10:14:30.438638 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:30.439006 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:30.439203 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:31.851651 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:31.851675 UTC - [Main Thread]: D/Focus Shift Focus: a
2016-10-17 10:14:31.851679 UTC - [Main Thread]: D/Focus  Flags: 1002 Current Window: 7fa03c998c20 New Window: 7fa03c998c20 Current Element: 0
2016-10-17 10:14:31.851681 UTC - [Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 1 SendFocus: 1
2016-10-17 10:14:31.851682 UTC - [Main Thread]: D/Focus <<Blur begin>>
2016-10-17 10:14:31.851693 UTC - [Main Thread]: D/Focus Element (none) has been blurred
2016-10-17 10:14:31.851695 UTC - [Main Thread]: D/Focus Update Caret: 0 1
2016-10-17 10:14:31.851699 UTC - [Main Thread]: D/Focus <<Focus begin>>
2016-10-17 10:14:31.851702 UTC - [Main Thread]: D/Focus Element a has been focused
2016-10-17 10:14:31.851703 UTC - [Main Thread]: D/Focus  from html
2016-10-17 10:14:31.851705 UTC - [Main Thread]: D/Focus  [Newdoc: 0 FocusChanged: 1 Raised: 0 Flags: 1002]
2016-10-17 10:14:31.852903 UTC - [Main Thread]: D/Focus Update Caret: 0 0
2016-10-17 10:14:31.852910 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:31.853175 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:31.853379 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:40.138851 UTC - [Main Thread]: D/Focus <<SetFocus begin>>
2016-10-17 10:14:40.138867 UTC - [Main Thread]: D/Focus Shift Focus: input
2016-10-17 10:14:40.138870 UTC - [Main Thread]: D/Focus  Flags: 1002 Current Window: 7fa03c998c20 New Window: 7fa04f273c20 Current Element: 0
2016-10-17 10:14:40.138872 UTC - [Main Thread]: D/Focus  In Active Window: 1 In Focused Window: 0 SendFocus: 1
2016-10-17 10:14:40.138876 UTC - [Main Thread]: D/Focus <<Blur begin>>
2016-10-17 10:14:40.138887 UTC - [Main Thread]: D/Focus Element (none) has been blurred
2016-10-17 10:14:40.139527 UTC - [Main Thread]: D/Focus <<Focus begin>>
2016-10-17 10:14:40.139533 UTC - [Main Thread]: D/Focus Element input has been focused
2016-10-17 10:14:40.139535 UTC - [Main Thread]: D/Focus  from window
2016-10-17 10:14:40.139537 UTC - [Main Thread]: D/Focus  [Newdoc: 1 FocusChanged: 1 Raised: 0 Flags: 1002]
2016-10-17 10:14:40.140911 UTC - [Main Thread]: D/Focus Update Caret: 0 1
2016-10-17 10:14:40.140919 UTC - [Main Thread]: D/Focus <<SetFocus end>>
2016-10-17 10:14:45.035499 UTC - [Main Thread]: D/Focus Window 7fa04f273c20 Lowered [Currently: 7fa04f273c20 7fa04f273c20]
2016-10-17 10:

Comment 107

[WADA:World Anti-bad-Duping Agency]

(In reply to p_zeller from comment #105)

First of all.
Please don't paste long trace log data to comment of bug in B.M.O.
It's not so easy to read bug, if lo-ng comment is written.
Please save part of log in a text file, and please attach the text file to this bug.

> While logging I lost focus on a new-message window which I just opened.
> Clicking on the window did not bring focus back.

Which phenomenon?

[ A : original phenomenon of this bug ]
> (A-1) Foreground(topmost)/Active Window = Composer
>       Messenger Window is a background Windows(not minimized)
> (A-2) After open Toaster Popup/close Toaster Popup by Thunderbird :
>       Foreground(topmost) Window = Composer (Active/Non-Active is unknown)
>       Messenger Window is still placed at back of Composer Window.
> (A-3) Keyboard Events is sent to Messanger Window.
>       i.e. Keyboard Focus is stolen by, or passed to, Messager Window.
Note-12 many are reports on non-latest MS Windows.

[ B : it sounds for me that your case is following phenomenon ]
> (B-1) Foreground(topmost)/Active Window = Composer
>       Messenger Window is a background Windows(not minimized)
> (B-2) After unknown event(s) :
>       Foreground(topmost) Window = Messanger (Active/Non-Active is unknown. Perhaps Active)
>       Composer Window is placed at back of Messenger Window.
> (B-3) Keyboard Events is sent to Messanger Window.
>       It's pretty natural phenomenon,
>       because Foreground(topmost)/Active Window usually has Keyboard Focus.
> (B-4) When Compioser Window, which is placed at back of Messenger, is clicked,
>       Composer Window stayed at back of Messanger Window.
>       Foreground(topmost)/Active Window is still Messenger Window.
Note-2: report on Linux.
Note-3: pretty similar phenomenon on latest Windows10 was recently reported at forum in Japan.
Used add-on = Lightning and Manually sort Folders only in this case.

You say you use following add-on.
> This is for Thunderbird 45.3.0 on Ubuntu 16.04 with the following
> extensions: Calendar Tweaks, Correct Identity, Enigmail, Exchange EWS
> Provider, Lightning, Messaging Menu and Unity Launcher integration, Provider
> for Google Calendar, Search Results Sort By Date Not Relevance

Do you see your problem by following?
- While you open Composer Window for mail composition, minimize Messenger Window.
 
Lightling tries to get Active Window state while messenger window is kept as background window?

Comment 108

[MD]

I upgrgaded to Windows 10 and both Firefox and Thunderbird when my WIN7 OS blew out.
SInce that time I have had this same experience. The parent window will grab the focus and now I am typing in another browser window or worse. archiving, deleting, ignoring threads etc.within Thunderbird. This issue clearly has been around for 3 years and not fixed so I really need a new mail client where I cannot wait 3 more for a resolution. If these programs do not play well with WIN 10 and it is a WIN 10 issue, then you need to not have it as dloadable for this OS. I sell on Ebay and all my records are kept through email notifications from them as well as paypal info. I cannot risk losing 1 single email as I need them for tax reasons. I am asking for help here, can someone tell me if there is ANY email program that is reliable and works with widnows 10, but most importantly, one that can import the 5 email profiles I have that I am using for Ebay etc. Any help will be greatly appreciated

Comment 109

[Kent James (:rkent)]

MD:

A few weeks ago, I enabled background slideshow to get this to show up in Windows 10 regularly. Drove me nuts. But I have not seen this happen at all since I did the workaround from https://bugzilla.mozilla.org/show_bug.cgi?id=1306773#c2  You might check that.

Comment 110

[Neil Deakin]

The log in comment 105 looks to be from Firefox, not from Thunderbird. Are you running both from the same prompt?

Neither log is showing any WidgetFocus logging so it though.

Comment 111

[WADA:World Anti-bad-Duping Agency]

Setting dependency to Bug 1258152 for ease of analysis, tracking.
Please see Bug 1258152 for phenomenon of [ B ] in Comment #107 on recent MS Windows10.

Comment 112

[MD]

(In reply to MD from comment #108)
> I upgrgaded to Windows 10 and both Firefox and Thunderbird when my WIN7 OS
> blew out.
> SInce that time I have had this same experience. The parent window will grab
> the focus and now I am typing in another browser window or worse. archiving,
> deleting, ignoring threads etc.within Thunderbird. This issue clearly has
> been around for 3 years and not fixed so I really need a new mail client
> where I cannot wait 3 more for a resolution. If these programs do not play
> well with WIN 10 and it is a WIN 10 issue, then you need to not have it as
> dloadable for this OS. I sell on Ebay and all my records are kept through
> email notifications from them as well as paypal info. I cannot risk losing 1
> single email as I need them for tax reasons. I am asking for help here, can
> someone tell me if there is ANY email program that is reliable and works
> with widnows 10, but most importantly, one that can import the 5 email
> profiles I have that I am using for Ebay etc. Any help will be greatly
> appreciated

UPDATE:
Issue for me was totally resolved in both Thunderbird and Firefox.
I never noticed the focus change was during Windows 10 slideshow switching pictures. Once I turned that off it stopped on both programs for me. Turn off slideshow and see if that helps you also
Where I found that info
https://bugzilla.mozilla.org/show_bug.cgi?id=1258152
This is a little more clear:
https://support.mozilla.org/en-US/questions/1129602

Comment 113

[Alan]

I have Windows 10 with slideshow turned off, but I still experience the temporary loss of focus (in Thunderbird) many times each day.

Comment 114

[MD]

(In reply to Alan from comment #113)
> I have Windows 10 with slideshow turned off, but I still experience the
> temporary loss of focus (in Thunderbird) many times each day.

Just wondering if you did it the same as I did. I went into advanced options to set it to pause. Did you do that or change it to a picture? 
As soon as I turned it on again, Thunderbird switched windows to the main window, so in my case this was definitely the cause, I was just about to switch email and browsers or even considered doing a fresh install of WIN 7 where this never occured for me even with my slideshow turned on.

Comment 115

[WADA:World Anti-bad-Duping Agency]

To all problem reporters on Win10 in Firefox and/or Thunderbird, with "Desktop background slideshow of Win10" + checking "Automatically pick an accent color from my background", or with manual accent color change or Theme chane at Desktop Personalization :

Phenomenon of "Re-ordering of  Firefox windopws and/or Thunderbird windows in such situation on Win10" is processed by Bug 1258152.
And, it was found that such phenomen on Win10 in Bug 1258152 is essentially same problem as Bug 1234317.
Difference between such phenomenon of Bug 1258152 and such phenomenon of Bug 1234317;
 Bug 1258152 : STR of this bug uses "Desktop background slideshow" + checking "Automatically pick an accent color from my background"
                     This is "automatic/periodical accent color change".
, Bug 1234317 : STR of this bug uses "manual accent color change" at Personalization>Colors, or uses Theme change etc. of  Desktop Personlization.

Comment 116

[MD]

(In reply to WADA from comment #115)
> To all problem reporters on Win10 in Firefox and/or Thunderbird, with
> "Desktop background slideshow of Win10" + checking "Automatically pick an
> accent color from my background", or with manual accent color change or
> Theme chane at Desktop Personalization :
> 
> Phenomenon of "Re-ordering of  Firefox windopws and/or Thunderbird windows
> in such situation on Win10" is processed by Bug 1258152.
> And, it was found that such phenomen on Win10 in Bug 1258152 is essentially
> same problem as Bug 1234317.
> Difference between such phenomenon of Bug 1258152 and such phenomenon of Bug
> 1234317;
>  Bug 1258152 : STR of this bug uses "Desktop background slideshow" +
> checking "Automatically pick an accent color from my background"
>                      This is "automatic/periodical accent color change".
> , Bug 1234317 : STR of this bug uses "manual accent color change" at
> Personalization>Colors, or uses Theme change etc. of  Desktop Personlization.

Holy smokes! That was it! I went into the color setting and unchecked to automatically pick a color, turned slideshow back on and slideshow now works normally and Tbird and Firefox do NOT switch focus. What a silly setting that is, all it does is take a color from your background and color the tiles you see when pressing the windows key!
                               >>>>>>>>>>>>KUDOS TO WADA<<<<<<<<<<<<<<<<

Comment 117

[WADA:World Anti-bad-Duping Agency]

This bug may be same problem as Bug 1234317(and "accent color change" case in Bug 1234317 too).

(1) Messenger window is minimized, then restored from Taskbar
    => as written in Bug 1234317,
       mLastSizeMode == nsSizeMode_Minimized is still kept,
       because nsWindow::OnWindowPosChanging never does mLastSizeMode=mSizeMode in this case,
       and because nsWindow::OnWindowPosChanged never does mLastSizeMode=mSizeMode in this case.

(2) When other window such as New Mail Alert is opened
    and it's get focus and it's placed at top of Thunderbird windows,
    Z-Order of Messenger window is perhaps changed,
    so WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED is perhaps sent to Thunderbird windows.
    nsWindow::OnWindowPosChanging does do nothing in this case.
    nsWindow::OnWindowPosChanged does do following in this case:
      if (mLastSizeMode != nsSizeMode_Normal && mSizeMode == nsSizeMode_Normal)
         DispatchFocusToTopLevelWindow(true);
    Because mLastSizeMode is still nsSizeMode_Minimized, DispatchFocusToTopLevelWindow(true) is executed.
    Because no one does do mLastSizeMode=mSizeMode, mLastSizeMode==nsSizeMode_Minimized is kept.

(3) When the other window such as New Mail Alert is closed,
    Z-Order of Messenger window is perhaps changed,
    so WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED is perhaps sent to Thunderbird windows.
    nsWindow::OnWindowPosChanging does do nothing in this case.
    nsWindow::OnWindowPosChanged does do following in this case:
      if (mLastSizeMode != nsSizeMode_Normal && mSizeMode == nsSizeMode_Normal)
         DispatchFocusToTopLevelWindow(true);
    Because mLastSizeMode is still nsSizeMode_Minimized, DispatchFocusToTopLevelWindow(true) is executed.
    Because no one does do mLastSizeMode=mSizeMode, mLastSizeMode==nsSizeMode_Minimized is kept.

(4) If Composer window is also minimized and restored from Taskbar at least once,
    same event as (2)/(3) happens at Composer window too.
    If (2)/(3) at Messenger and (2)/(3) at Composer happens at same time.
    final focus winner is unpredictable.

I think current nsWindow::OnWindowPosChanging and nsWindow::OnWindowPosChanged works well
only when SizeMode change actually occurred.
It doesn't seem to work well if WM_WINDOWPOSCHANGING and WM_WINDOWPOSCHANGED is sent to Thunderbird/Firefox windows
when the windows are minimized and restored once
and the windows are kept as Foreground window or Background window with mSizeMode==nsSizeMode_Normal.

I don't know design/spec/code of DispatchFocusToTopLevelWindow(true).
But it looks for me that DispatchFocusToTopLevelWindow moves focus to caller window instead of current topmost window(highest Z-Order window) among Thunderbird windows(and/or Firefox windows).

Comment 118

[WADA:World Anti-bad-Duping Agency]

Sorry, wrong bug number in previous comment.

(and "accent color change" case in * Bug 1258152 * too)

Comment 119

[WADA:World Anti-bad-Duping Agency]

https://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#4268
DispatchFocusToTopLevelWindow(true) does following.
 If this windows's wintype is eWindowType_toplevel or eWindowType_dialog,
    nsWindow *win = WinUtils::GetNSWindowPtr( this window );
    win->mWidgetListener->WindowActivated();
 Else (child window case. A child window is owned by one toplevel window only)
    Find parent, parent of parent, ... , parent of parent of ... parent of parent, 
       which has eWindowType_toplevel or eWindowType_dialog attribute.
    If found,
      nsWindow *win = WinUtils::GetNSWindowPtr( the found toplevel or dialog window );
      win->mWidgetListener->WindowActivated();

It looks this code assumes "only one eWindowType_toplevel window among Thunderbird window".

In recent MS Windows, it seems multiple eWindowType_toplevel windows exist in one Thunderbird instance.
And, it seems that these "multiple eWindowType_toplevel windows in one Thunderbird instance" are ordered by Z-Order value.

If not, why focus is moved like Win1->Win2->Win3->Win1->Win2->Win3->Win1->Win2->Win3(3 times trip) by Bug 1234317 in a Thunderbird instance and in a Firefox instance? 
If not, why Active/Foreground window is changed according to focus switch in Bug 1234317?
See https://msdn.microsoft.com/en-us/library/windows/desktop/ms632599(v=vs.85).aspx#zorder

Comment 120

[KitchM]

Yes, but this is not a Windows bug report.  It is Linux.  Does the same apply?

Comment 121

[WADA:World Anti-bad-Duping Agency]

(In reply to KitchM from comment #120)
> Yes, but this is not a Windows bug report.  It is Linux. 

But this bug is never for Linux only problem, even if initial report was for Linux, and even if Platform:Linux is still set.
Problem report by Comment #4 is obviously phenomenon on MS Win7.
Sorry but we don't have "Platform:Linux and Win only, Not Mac" setting.

> Does the same apply?

Following seems code invoked upon Z-order change event at foreground/background window on Linux.
https://dxr.mozilla.org/mozilla-central/source/widget/gtk/nsWindow.cpp#3305
nsWindow::OnWindowStateEvent(GtkWidget *aWidget, GdkEventWindowState *aEvent)

It looks that code cares following SizeMode change case only.
  normal->minimized(ICONIFIED), minimized(ICONIFIED)->normal (==restore to normal) 
  normal->maximized, maximized->normal
It doesn't look to care "windowstatechange event between normal->normal" case.
If "event of Z-Order change" is notified from Linux to Firefox/Thunderbird windows,
and If something wrong exists in Z-order change handling on Linux too,
similar problem may occur on Linux.

On Linux, phenomenon/cause may be different from Win, even if external symtom is same or similar.
Bug like following may affect on our phenomenon on Linux.
  Bug 156333 - GetZOrderDOMWindowEnumerator is broken on Linux
               (new message count not updated when multiple mail windows are present) 
similar phenomenon to one on MS Win may occur.


 Does the same
> apply?

Comment 122

[KitchM]

I should mention a related issue that I have seen in Firefox when I am creating a new bookmark folder or in Thunderbird creating a new mailbox folder.  The related pop-up window just sets there and no text is entered in the field while I type.  I have to grab the window with the mouse and move it around for the cursor to become active.  The amount of required movement varies.

Comment 123

[Alan]

The situation seems worse in 45.6, in two ways.  The loss of focus is occurring with greater frequency, and sometimes it is causing a crash.  Additionally, the crash does not invoke the Thunderbird crash reporter.

Comment 124

[Alan]

The situation seems substantially better in 45.7.  I am no longer seeing crashes associated with the loss of focus.  In addition, during the period when focus is lost, windows are no longer temporarily rearranged on the desktop.  (Windows 10.) Furthermore, key strokes and mouse clicks during the period of lost focus now seem to be captured by Thunderbird rather than by other applications (thank goodness); they just are not processed until focus returns to Thunderbird.

The recently reported bug 1334855 is likely related to this bug.

Comment 125

[KitchM]

I should reiterate that while some people have mentioned crashes, that is not what this issue was regarding.  It remains one where the loss of focus of the foreground window happens in TB during typing of a reply or new message.  This normally happens after the program has been open for a period of time.  Restarting it may stop this from happening for a short time, but it usually gets worse, with the length of time between restarts and recurrence becoming shorter.  Only starting a new edit window (otherwise known as starting the same e-mail reply or new message) stops the problem.  But of course, the user must close the duplicate after sending of the second one.

While crashes may occur, especially if one is using Windows, that is most likely not associated with this situation.

Comment 126

[MD]

Please see comments 115 and 116 for the solution that worked for my 3 computers this was happening on after upgrading each to WIN 10. That solution worked on all 3 machines with fresh installs. It was affecting TB and also Firefox. The solution stopped both issues.

Comment 127

[KitchM]

That a solution works for your problem still does not mean it fits in this issue.  The problem is that it confuses the issue originally posted here and never fixed.  We certainly do not want to ever imply that the issue is fixed in any way, shape or form.  It is not.

Comment 128

[MD]

Excuse me? Here is the bug
Bug 942610 - Reply Window Loses Focus during typing and typed characters is sent to non-front-most window, when focus is stolen by main window or toaster popups (new message alert) 

Wada gave the solution to THIS bug which is the subject and the issue which worked for me and to which I replied. 

What bug are you talking about?

Comment 129

[Alan]

That solution (comment 115,116) does not work for me.  I also doubt the crash problem was unrelated: it definitely happened in exactly the same (unwanted loss of focus) conditions.  It also went away at the same time as the focus issue improved (as I reported above).

Comment 130

[KitchM]

MD, the bug you linked to is this bug.  What are you referring to?

Alan, are you on Microsoft?

Comment 131

[Alan]

KitchM: Yes, as I reported I am on Win 10.

I need to correct something: mouse click that coincide with the unwanted loss of focus are not always captured by Thunderbird.  Still, I no longer see the old and dangerous problem of clicks and keystrokes in Thunderbird reaching other applications when Thunderbird loses focus.  (Here's oping that is reliably true!)

Comment 132

[MD]

I was referring to your comment. I was quoting this exact bug, there appears to be some confusion as to the bug title indicating crashes when it is reporting only a focus issue. I then posted my comment that Wada's fix worked for me for this bug, the focus issue. Not sure why there is so much confusion about what I posted. If there are people having crashes that would be a different bug title. It may include this focus issue but this bug is referring only to that issue. There are tons of bug issues, some are related some are not.

Comment 133

[KitchM]

The confusion seems to come in when people do not read that this is reported on a Linux platform.  There is no way that one can compare the instability of Windows with Linux issues.  Linux issues most usually have to do with the program itself.  Windows issues most usually have to do with the operating system.  These are two completely different situations.

If the loss of focus in TB is occurring in other operating systema, there may be some crossover rationale.  However, crashing the program or the OS is certainly not a Linux issue.

Diagnosing computer issues requires a great deal of precision and exactitude.  Any single variable throws the whole diagnosis into question and simply causes unnecessary confusion when I and others are trying to solve a very old issue that is very specific to the program itself.

I trust everyone understands the significant difference.

Comment 134

[Alan]

MD: Again, your "solution" worked for you, not for me, in fixing the loss of focus issue.  Reporting the crash *here* is relevant because I observed the following sequence: loss of focus, then crash.  This may prove useful in diagnosis of the loss of focus issue, so it is worth reporting.  Additional evidence of its possible relevance came with the last update: the (loss of focus -> program crash) issue went away, and there was also substantial improvement on the loss of focus issue (i.e., it still happens, but without window rearrangement, and so far without keystrokes intended for Thunderbird reaching other applications as they have done since this loss of focus issue began).

KitchM: It is true that I am assuming that the cross-platform loss of focus experience represents a single issue that is appearing across platforms.  This possibilitiy should be taken seriously, right?

Comment 135

[MD]

Sigh, I never said this would work for everyone. All I said is the solution worked for me in Windows 10. That is all. So anyone with windows 10 is welcome to try Wada's solution. Again, it may not work for you but it worked for me. That is simply all I have been saying. Clearly there is a coding issue, windows 10 and linux seem to be having problems
TB support may have a short life left according to this article. We may be looking for a new client

https://techcrunch.com/2015/11/30/thunderbird-flies-away-from-mozilla/

Comment 136

[KitchM]

Okay, I understand both you guys.  I really do.  However, MD, let me be clear that the issue for this bug is having to do with loss of focus only.  And that is on a Linux platform only.  Therefore, bringing a crash into the picture when no such thing existed in the original bug does not actually help.  I really do understand how someone might think that.  Sadly, that is not how diagnostics work in software.  Since the results are different in different platforms, the two separate bugs are not the same.

Alan, you are correct that this should be taken seriously as a cross-platform loss of focus bug.  Especially as this has existed for so very long.  At first I had thought it might have something to do with my desktop environment.  However, seeing it on various platforms pretty much rules that out.

To everyone, I just read something about TB just the other day that said TB programmers are busy with security issues.  That seems to indicate that there are not enough programmers to address these other bugs.  I get it.  They do need funding for some new programmers and a programming manager.  I just wish Mozilla would at least start a crowd-funding effort for a TB rewrite.  I'd contribute again as long as I can be sure of what the money would go for, and I believe most people feel that way as well.

In any case, as MD's linked article indicates, there are problems.  The confusion displayed by the manager clearly is evident and is what creates the problems.  These usually start when "coders" begin being called "engineers", as well as the bizarre fixation on needing to tie one program with the other.  No wonder there are such problems.

Comment 137

[MD]

Yes Kitch, all I was having on my platform was the focus issue, never had a crash from it, but again, thats win 10.
The issue in TB was bad. If I hit reply to and was typing the reply, as soon as the machine would refresh my tile screen (every 1 minute)it would take TB main and move it to front. If I was typing and didn't notice this (I have to watch my fingers :( )I would trigger all kinds of shortcut keys archiving mail and other undesirable things.
In my case on this platform turning off screensaver (per Wada earlier post) at first did the trick. Then Wada posted if you simply go one level deeper and untick the box to automatically pick your tile color from your current wallpaper, it totally stopped. This was also happening in Mozilla. If I had multiple windows open (and I have tons always (as I sell on Ebay) The first window would come back to the front every 1 minute, blocking the window I was using. I truly hope that TB sticks around as I am just too used to using pretty much since release.
The funny thing is same machine, but I never had this problem with Win7, it started when I upgraded.

Comment 138

[KitchM]

I too am having trouble changing from TB, and really would rather not.  But......

Here's a couple thoughts based on you comments.  Screensavers are always a bad idea on any platform I've tried.  I have spent too much time over decades trying to solve their problems and they simply are not worth it.  A good monitor can be set to turn off after a period of screen inactivity or one can simply turn it off manually.

I don't believe that the number of displays one uses should make any difference. but Windows can have many problems and multiple programs is certainly one of them.

Why not load up a system with your favorite Linux distro and see what happens?  You will have a better idea of what you did that made the difference and which parts of that are Windows-based, as well as learning the difference between OS platforms.

By the way, we don't know what you mean by "Mozilla".  Did you mean Firefox, Lightening, Gecko or.....?

Comment 139

[MD]

LOL I forgot to put which software. I was referring to Firefox. Also Kitch it isn't the screensaver, it is the wallpaper. In win 10 it rotates your wallpaper through a slideshow.
I wish I had the energy to try and learn a new platform but I just dont think I could go through it. I have been involved in IT now for about 25 years (never coding, just desktop support)and I am a bit familiar with the older version of Linux as I worked for a short while in the early days on UNIX a bit. Also may have touched on a version called red hat I think? I could be way off base ion that statement though

Comment 140

[KitchM]

When we associate two programs with one problem, at least in this bug's case, it only leads to confusion.  This issue is about TB only.

With that said, MD, your next problem is trying to diagnose the problems of wallpapers and screensavers.  One must be precise as to the details of the problem.  Static background images only appear to cause problems when the system lacks enough memory.  However, slideshow backgrounds are the same as screensavers in that they both are problematic in operating systems because of the fact that they add another unnecessary process to the system, thereby tying up system resources.  Windows is particularly unable to handle too many processing streams at one time.  Therefore, all Windows users should close anything they do not need.

Besides, why one wants a slideshow in the background when other programs take up the screen is beyond me.  In any case, your crashes were clearly caused by an overloaded system.  Desktop support people are supposed to know better.  If you want a fairly stable Windows environment, get rid of any background task but for firewall and antivirus software.  Decide if your computer is for play or business before opening any programs.  It can't do both at the same time.  They way one tests the performance of a system has traditionally been to use extremely demanding game play.  Such require all of the resources available in the system.

By the way, if you wish to try a Linux distro, it has always been very easy.  Simply download an ISO image of something like Ubuntu (RedHat is the commercial enterprise product that is the most popular in the world today), and then create the bootable DVD.  Then simply boot off of it and give it a try.  No changes are ever made to you system.

Comment 141

[MD]

Hey Kitch. Again, I am not having any crash issues nor have I said I did in any of my posts, that wasn't me that was someone else. All that was happening to me is what I said. As far as wallpaper changing, that is built into windows and on by default. Every user who uses windows 10 has it on, I certainly never turned it on, it was already on. They would have to go in and find this color setting (not easy to just find) to untick it. 
I didn't think it confused this bug issue by having two issues resolved by the fix and very much worth mentioning. I mentioned in this bug fix that not only did that fix stop TB from messing up it also fixed Firefox which had identical focus issues. It is definitely a coding issue on Mozillas end.
I like the fact that the wallpaper changes which certainly is  a user preference. I use 2 screens and one is for reference only usually in the event I need to look something up if the other screen is busy. I have 24G of memory and a 4850 8 core processor, I really do not think a tiny footprint piece of software is wasting any resources by using it. If that is true, then Microsoft needs to get out of the OS business...seriously. My system is FAR from being overloaded plus I do not crash.
A fresh install of Windows 10 has prolly more than 40 processes running all at once, most not being used.
Also, the wallpaper change works perfectly with every single other program, it only has issues with Mozilla programs. (Please try and keep things on the civil side, I have been working on computers for  near 30 years and I do know better, I am really not a stupid person and was a supervisor at a helpdesk before I retired 3 years ago.)
All I have been doing is sharing my success with one fix that fixed a particular OS having this issue. That is all.
Again, I have never experienced a crash you may be confusing my post with Alan's I think.
I may try and look at your idea for Linux where it will not affect the Window install, I did not know Linux would run off a disk so thanks for that.

Comment 142

[KitchM]

Sorry, MD, you are correct.  I was referencing Alan's issue.  The problem is common to Windows.  I apologize for confusing the issue by mixing them together.

The background slideshow/screensaver issue is still relevant for the rest.  You are correct in that new Windows users must take a lot of time trying to find settings for default processes which are unnecessary and damaging, and almost impossible to turn off.  The vast number of concurrent processes you mentioned does create problems, and issues with memory handling and process isolation is not helped by more powerful processors or more memory.  If those things helped, Windows would have had no more problems since the availability of modern hardware.

Actually, the fact that Window's settings had to be changed to make a program work still likely makes it a Windows issue and not a Mozilla code problem.  The OS should keep the programs separate from each other and itself.  (And you are quite right that Microsoft needs to be out of the OS business. ;) )

No offence, but everyone in help desk situations are supposed to tell clients to first turn off all background tasks.  This has always been the first step in diagnosing problems.  I simply got the impression that you did not do that.  Your confusion over using this post for a non-related issue was a second red flag.  Further, if I were your client I would be confused by your use of the word "screens".  When you mention "screens", do you mean monitors, desktops or ..?  (For instance, I currently have six desktops running on one monitor.)  You may have spent loads of time trying to help others, but I would not know that by your lack of precision.  Sorry.

Comment 143

[MD]

I mean monitors, in work, we called them screeens, if we were referring to separate windows on any screen we might ask how many windows they have open or how many desktops. they understood that just fine, it was fairly precise. To us, if we wanted a single monitor computer to have a second one we would ask IT to please add a second screen or order us a second one we will install. They liked their own IT guys to do any mods,  I am confusing you with my replies so maybe we should just call it at this point as we certainly are not helping others going back and forth asking for clarity on terminology.
I am not offended by your comment about turning off background programs, but until you know the software we supported and hardware, that was NOT the first thing you would ever do. I would write up my tech if he did that rather than reinitialize credit, or the pinpad or some other peripheral If a stores credit stopped running, we would reinitialize it. Not all troubleshooting fits all, we did just fine and supported over 1500 store chains including Coach, Jcrew Aeropostale. 
As far as your last comment about my lack of precision, I am sorry you do not understand the things I am trying to say. I am incredi9bly thorough and have a passion for my trade

Comment 144

[KitchM]

Understood.  I assumed it was just normal Windows support. That was not clear.

But I think I understand now that it does sound like you were working in a corporate setting and that you were trying to run things like POS software on Windows.  Such things need dedicated operating systems to work properly and nothing else running to slow things down.  Yes, one could try restarting a given device, but once it becomes a program issue, removing all background tasks is still the first thing to do.  Especially in normal support scenarios where personal computers are running many apps.

In Bugzilla there is a need for details, and the proper diagnostics for programs reported here, especially for Windows apps, will always be to eliminate every extraneous process to get down to the bare minimum.  I just wish everyone would remember that for the sake of the programmers who try to figure out what went wrong.  They do not have time to do the elimination process for us.

Comment 145

[MD]

Understood as well and glad we are on the same page. I gave all the details I needed to really. I had the exact issue in the bug (in win10 not linux and missed the OS in the bug report) and responded that I did the 3 steps Wada reported to fix it on a Win10 machine and that it worked. I really couldn't have embellished it any more than that. Glad anyway we got through that and I hope maybe if someone does have Win10 and stumbles here that maybe, just maybe, that will work for them as well.

Comment 146

[thibaut]

Hi,

I'm using Debian Stretch (the upcoming release). This bug affects me when I run Icedove (the Debian rebranded version of Thunderbird) under the default, X11-based GNOME as well as under other X11-based desktop environments, but not when running under the Wayland flavor of the GNOME session.

In addition, I have noticed that the focus issue is way worse when the lightning pane is developed. Then it can be impossible to recover focus in a composer window until I select again the mail folder pane in the main window.

On my box, the focus problem can occur both ways, i.e. sometimes the focus stays in a composer window when I click in the main window. Opening a new composer window recovers normal focus behavior.

Regards, Thibaut.

Comment 147

[KitchM]

I find that highly significant.  Wayland is a replacement for X11, for those who don't know, and I have always felt the loss of focus issue was a desktop environment-related problem, or more specifically, a windowing system issue.

It may very well be that Thunderbird has been programmed in such a manner that it is not well isolated from the environment as well as it should be.  While I realize that it could be the issue of a lack of necessary consistency within the workings of the DE and its windowing system, that it should happen on Windows and various Linux flavors is pointing me to a TB programming problem.  Also, restarting it will often give respite for a short period of time.

I'm in favor of requesting the programmers having a look at the specific relationship between the TB code and the windowing system within which it is to operate, if they would be so kind.  This narrows down the possibilities enormously.

Comment 148

[KitchM]

Or the display server.  Forgot to be properly inclusive.

Comment 149

[till]

Since updating from Ubuntu 14.04 to Ubuntu 16.04 three months ago, I am constantly affected by this bug (i.e. focus is stolen, but no crashes). Since I am using Ubuntu, this is definitely not a Windows bug. Restarting TB helps for some time, but not long. Currently, I need to restart TB several times a day. It is really annoying.

Comment 150

[Kevin Kempfer]

Same here on Ubuntu 16.04 and Thunderbird 45.8.0
Is there anything I can provide to help fix the problem? 
Restarting Thunderbird every hour is really annoying.

Comment 151

[Wayne Mery (:wsmwk)]

NOTES: 
1. users who FIRST encountered this in version 45 are/were likely seeing bug 1258152/bug 1234317 which is fixed in version 52
2. users who didn't FIRST see this in version 24 might be in the wrong bug report

See comment 101 for debugging info.

So, who still sees this in version 52?

Comment 152

[Alan]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #151)

Loss of focus issue still exists in version 52.  Input to Composer window is still occasionally lost when focus is lost while typing.

Comment 155

[Alan]

Loss of focus issue is a bit worse in version 52.5.2: more frequent, and longer lasting.

Comment 156

[Erik Blake]

Although this thread is old (4 years), I've not noticed this behaviour until upgrading to the current 52.6.0.

Although likely unrelated, this release also brought with it phenomenally long processing times when fetching new mail (high CPU cycles, and Thunderbird largely unresponsive for several minutes while it fetches emails and runs filters). If trying to compose an email during this time, typed letters in the composition window are lost, even if it does not lose focus.

Comment 157

[Erik Blake]

I once again echo the comment of Edward Henigin from 5 years ago: "Mailbox mayhem ensues when the main windows steals focus from a compose window in which I'm typing."

This is happening with the latest 60.6.1 on Win10-64. This has happened twice for me this morning! The change in focus from the compose window to the main window is not momentary - focus stays in the main window until you notice and click the mouse in the compose window to bring focus back.

Either this needs to be fixed (why would the main window ever execute SetFocus?), or there has to be a way to disable the single-letter command shortcuts like A, T, N, K, F, B, P, R, S, C, J, etc. The SHIFT letters C, J, and K are also a problem since users do type capital letters in emails.

Commands like "archive" are, in this situation, easily-typed because the letter "A" occurs frequently in English.

Comment 158

[KitchM]

I must agree with Erik Blake.

It has become apparent to me that this problem seems to come and go. The last two OS versions I have used have eliminated the problem. Therefore, the issue appears to obviously be regarding TB and the environment.

This would then seem to indicate that TB has been programmed with an unnecessary reliance upon outside parameters which should have no bearing upon the inner workings of the program nor the relationships between the various windows of the program. There must be a differentiation between the windows and the environment, and the windows and the program's switching between them.

Can this line of reasoning help some in the solving of this issue? Do any programmers out there wish to respond?

Comment 159

[Erik Blake]

Is there any way to turn off the ill-conceived hot-keys based on single letters (A, T, N, K, F, B, P, R, S, C, J, and SHIFT C, J, and K )? I am tired of unintended actions when I'm typing an email.

Comment 160

[KitchM]

Different computer now (brand new) with old configuration of Fedora 20 and TB 31.7.0. Problem showing up again, so may be because of old version. Just posting this as a reference.

Comment 161

[Eliot Moss]

This started happening to me under Windows 10 (insider slow track), TB 68.8.0.
It is super annoying. My only workaround is to use an external editor add-on
and go into emacs to edit every message. Really tedious.

It doesn't tend to show up instantly, so some short replies are ok, but I'd say
there's a good chance ti will hit within the first 100 keystrokes.

Comment 162

[KitchM]

I have been using Debian 10 with Xfce 4.12 for some time now, as well as keeping TB up to date automatically. Since that point, I have not had any experience with this problem any longer. I certainly wish I could say exactly what has changed, whether improved programming code or better environment, but it is at least significant enough to report.

I truly understand the maddening nature of the issue. It is a PITA. There is no doubt about that.

One possible way to help diagnose this would be to create a dual-boot setup on a computer and try a different operating system (OS). If you are windows, try Linus, and if you are Linux, try a different desktop environment (DE). There are a lot of combinations to try and this can help in two ways. First, it can eliminate the possibilities of the personal customization conflicts with the existing OS. Second, it can offer a radical change to the computing environment as a whole. Sometimes stepping back and making a big change can adjust our viewpoint of focus on the issue. Storing our profiles on a separate drive makes backing up easier and it also allows the same profile to be used in multiple environments more easily.

Comment 163

[Wayne Mery (:wsmwk)]

Does this still reproduce for you?

Comment 164

[Eliot Moss]

I've moved on version 102.12.0 these days, and I was able to make the External Editor work (a newer version designed for the newer stream of Thunderbird).

Comment 165

[Alan]

(In reply to Wayne Mery (:wsmwk) from comment #163)

Does this still reproduce for you?

No, I am no longer seeing the buggy behavior.

Comment 166

[Erik Blake]

Yes, I am still seeing this happen with 102.12.0 (64-bit). It is less frequent, but seems to be associated with TB initiating processes on it's own (e.g. syncing, or compacting). The compose window will drop into the background.

I have mitigated the consequences of these unwanted changes in focus by using the tbkey-lite extension to disable all the single-letter commands. Now it's just irritating, instead of causing more serious effects.

Comment 167

[KitchM]

I have not noticed this recently.

Comment 168

[Wayne Mery (:wsmwk)]

Thanks for the update.