Closed
Bug 570267
Opened 14 years ago
Closed 14 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 Graveyard :: Plug-ins, defect)
Tracking
(blocking2.0 final+, status2.0 wanted, blocking1.9.2 needed, status1.9.2 .9-fixed)
RESOLVED
FIXED
mozilla2.0b1
People
(Reporter: rshimazu, Assigned: Felipe)
References
()
Details
Attachments
(3 files)
980 bytes,
text/html
|
Details | |
5.19 KB,
patch
|
jimm
:
review+
|
Details | Diff | Splinter Review |
4.13 KB,
patch
|
christian
:
approval1.9.2.9+
|
Details | Diff | Splinter Review |
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.
Updated•14 years ago
|
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
Updated•14 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•14 years ago
|
||
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.
Comment 4•14 years ago
|
||
Interesting, clicking between notepad and the plugin seems to work every other time. Kind of strange.
Updated•14 years ago
|
blocking1.9.2: ? → needed
Updated•14 years ago
|
Assignee: jmathies → felipc
Comment 5•14 years ago
|
||
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.
Assignee | ||
Comment 6•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #451404 -
Flags: review?(jmathies) → review+
Comment 8•14 years ago
|
||
Comment on attachment 451404 [details] [diff] [review] Let the parent now of lost focus on child process This looks ok to me.
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Comment 9•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/75a2d19c2590
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a6
Comment 10•14 years ago
|
||
Will this patch be part of FF 3.6.7 as well, or is there an extra patch/check-in needed?
Reporter | ||
Comment 11•14 years ago
|
||
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?
Comment 12•14 years ago
|
||
Felipe, can you request branch approval, assuming this patch is branch-correct?
Assignee | ||
Comment 13•14 years ago
|
||
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?
Assignee | ||
Comment 14•14 years ago
|
||
(Posting an hg export of the current patch updated to branch's tip.)
Attachment #451404 -
Flags: approval1.9.2.8?
Comment 15•14 years ago
|
||
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+
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [c-n 1.9.2 default]
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•