Closed Bug 570267 Opened 10 years ago Closed 10 years ago

[OOPP] Firefox 3.6.4 bug: When a flash file has a focus, window.onblur event does not happen as expected.

Categories

(Core :: Plug-ins, defect)

1.9.2 Branch
x86
Windows Vista
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b1
Tracking Status
blocking2.0 --- final+
status2.0 --- wanted
blocking1.9.2 --- needed
status1.9.2 --- .9-fixed

People

(Reporter: rshimazu, Assigned: Felipe)

References

()

Details

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4 GTB7.0 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.4) Gecko/20100527 Firefox/3.6.4 GTB7.0 ( .NET CLR 3.5.30729)

Maybe because of a new OOPP.
In Firefox 3.6.4, when a flash file has a focus, window.onblur event does not happen as expected and wrongly report "document.hasFocus is true" even when it loses focus.

Reproducible: Always

Steps to Reproduce:
1. Access to a demo page: http://www.broadband-xp.com/test/ff364/ff37_demo.html
with Firefox 3.6.4 .
2. Set focus on a flash.
3. Run another application like notepad over  Firefox.
Actual Results:  
This does not bring about window.onblur event but wrongly report that document.hasFocus() is true.

Expected Results:  
This should bring about window.onblur event and report that document.hasFocus() is false when another application's window in over Firefox's window.

This does not happen when I use Firefox 3.6.3. In my guess the introduction of OOPP must be relevant to this behavior.
If you change the value of dom.ipc.plugins.enabled.npswf32.dll to be false (in about:config), Firefox 3.6.4 behaves just as Firefox 3.6.3 does. It detects window.onblur as expected.
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins
Summary: Firefox 3.6.4 bug: When a flash file has a focus, window.onblur event does not happen as expected. → [OOPP] Firefox 3.6.4 bug: When a flash file has a focus, window.onblur event does not happen as expected.
Version: unspecified → 1.9.2 Branch
Build worked : 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4pre) Gecko/20100406 Namoroka/3.6.4pre

Build broken : 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4pre) Gecko/20100407 Lorentz/3.6.4pre

pushlog : 
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=965a31dcde02&tochange=ec534329e186
Status: UNCONFIRMED → NEW
Ever confirmed: true
I don't think this needs to block, but we should get it on the radar anyway. -> jmathies for the moment, but I'm going to try and find another owner.
Assignee: nobody → jmathies
blocking1.9.2: --- → ?
blocking2.0: --- → final+
status1.9.2: --- → ?
status2.0: --- → wanted
Attached file test case
Interesting, clicking between notepad and the plugin seems to work every other time. Kind of strange.
blocking1.9.2: ? → needed
Assignee: jmathies → felipc
From the little bit of testing I did on this - the failure appears to be related to the plugin receiving WM_KILLFOCUS. The plugin window does receive it, but for some reason that doesn't translate back to it's parent window, and in turn to the focus manager through the widget layer. We may need to handle this like we did with set focus, sending an ipc message over to plugin instance parent.
The way that the onblur event is raised is that after receiving a WM_ACTIVATE message (with inactivate as param), nsWindow waits for the WM_KILLFOCUS to actually dispatch onblur. On OOPP the parent only receives the WM_ACTIVATE, and the WM_KILLFOCUS goes to the child, and there was nothing informing the parent process of that.

The PluginGotFocus message existed. I could either create a new one (PluginLostFocus), or modify this one to PluginFocusChange with a param (that's what I did).

I'm just not sure what would be a good place to define the constants used to indicate focus/blur between nsWindow.cpp and PluginInstanceParent.cpp (or if I could just use PR_TRUE and PR_FALSE in the wparam)
Attachment #451404 - Flags: review?(bent.mozilla)
Comment on attachment 451404 [details] [diff] [review]
Let the parent now of lost focus on child process

jimm is a better reviewer for this, I think. I've been out of the loop for a little too long on these focus issues.
Attachment #451404 - Flags: review?(bent.mozilla) → review?(jmathies)
Attachment #451404 - Flags: review?(jmathies) → review+
Comment on attachment 451404 [details] [diff] [review]
Let the parent now of lost focus on child process

This looks ok to me.
http://hg.mozilla.org/mozilla-central/rev/75a2d19c2590
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Will this patch be part of FF 3.6.7 as well, or is there an extra patch/check-in needed?
As far as I confirmed, in Firefox 4.0 b1, this bug has already been fixed.

But I do not know much about Bugzilla and what "Target Milestone: 	mozilla1.9.3b1 " exactly means. Does this mean that this bug will be fixed only in Firefox 4.0 b1 and that it will not be fixed in Firefox 3.6.x?
Felipe, can you request branch approval, assuming this patch is branch-correct?
Comment on attachment 451404 [details] [diff] [review]
Let the parent now of lost focus on child process

(In reply to comment #12)
> Felipe, can you request branch approval, assuming this patch is branch-correct?

Yes, the patch applies to the branch with some fuzzing, and I've verified that it works and fixes the bug on the branch as well.
Attachment #451404 - Flags: approval1.9.2.8?
Attached patch Patch for 1.9.2Splinter Review
(Posting an hg export of the current patch updated to branch's tip.)
Attachment #451404 - Flags: approval1.9.2.8?
Comment on attachment 456950 [details] [diff] [review]
Patch for 1.9.2

a=LegNeato for 1.9.2.8. Please land this on mozilla-1.9.2 default, *not* a relbranch
Attachment #456950 - Flags: approval1.9.2.8+
Keywords: checkin-needed
Whiteboard: [c-n 1.9.2 default]
You need to log in before you can comment on or make changes to this bug.