372177 - No focus event fired when a window "gets focus" because another one has been minimized

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Thomas Bertels]

Steps to reproduce :
1. Open attachment 160548 [details] in a new window and click on the text field.
2. Click on this window in the taskbar then minimize it.

Actual Results :
No focus event fired when the attachment window becomes visible.
The text field is of course unusable.

This bug has appeared between

Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a3pre) Gecko/20070220 Minefield/3.0a3pre ID:2007022005 [cairo]
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9a3pre) Gecko/20070221 Minefield/3.0a3pre ID:2007022104 [cairo]

so bug 261074 could be the cause.

Comment 1

[Thomas Bertels]

Here are the checkins between the two builds : http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaBranchTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-20&maxdate=2007-02-21&cvsroot=%2Fcvsroot

Comment 2

[Ryuichi KUBUKI]

Related to Bug 371116 too?

Comment 3

[Oliver Yeoh]

Attachment: Patch

Bah!

Comment 4

[Ere Maijala (slow)]

Comment on attachment 257822 [details] [diff] [review]
Patch

When exactly is lParam 0? Is it documented somewhere?

Comment 5

[Oliver Yeoh]

(In reply to comment #4)
> (From update of attachment 257822 [details] [diff] [review])
> When exactly is lParam 0? Is it documented somewhere?
> 

lParam should be the window handle that would be activated/deactivated. However it is always NULL when switching between windows belonging to different processes.

I'm afraid it's not documented. I have tested this behaviour against XP and Vista and its consistent.

Comment 6

[Ere Maijala (slow)]

Comment on attachment 257822 [details] [diff] [review]
Patch

Please add that to the comment. I'm not feeling too convenient relying on undocumented behavior, but let's hope it remains the same. r=emaijala

Comment 7

[Oliver Yeoh]

Attachment: Patch for checkin

Added comment about the undocumented behaviour.

Ere, would you be able to help check this in? Thanks in advance :)

Comment 8

[Ere Maijala (slow)]

Checked in to trunk.

Comment 9

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070308 SeaMonkey/1.5a] (nightly) (W2Ksp4)

> (In reply to comment #4)
> I'm afraid it's not documented. I have tested this behaviour against XP and
> Vista and its consistent.

Same Toolkit bug (=> underlying Windows behaviour...) with W2K.

Comment 11

[Thomas Bertels]

Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070311 Minefield/3.0a3pre

Comment 12

[[e-mail]]

(In reply to comment #5)
>(In reply to comment #4)
>>(From update of attachment 257822 [details] [diff] [review] [details])
>>When exactly is lParam 0? Is it documented somewhere?
>lParam should be the window handle that would be activated/deactivated. However
>it is always NULL when switching between windows belonging to different processes.
> 
>I'm afraid it's not documented.
Strange, I was sure it was documented, but Microsoft might have revised it out.

Comment 13

[[e-mail]]

http://blogs.msdn.com/jfoscoding/Default.aspx?p=2
WM_ACTIVATE: This message activates the client area of the toplevel window.  The wParam specifies the fActive, and the lParam specifies which other window in the system was previously active.  This handle can be null and will be when the previously active window is not in the same thread.

Comment 14

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070311 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Confirming V.Fixed, with SeaMonkey.