294688 - clicking on applet or flash after context menu opens, does not close context menu

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Aaron Slunt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050515 Firefox/1.0+

If you open a context menu with right-clicking and just want to close it by left
clicking, left-clicking on an applet or flash will NOT allow the menu to close.
This is annoying, especially for pages that have flash movies full screen.

Reproducible: Always

Comment 1

[Aaron Slunt]

Attachment: testcase using flash

Just right click in the area outside of the flash, then left-click in the
flash, trying to close the menu.

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Firefox/1.0.4
Confirmed.
It _is_ annoying, because you can potentially have more than one context menu
open in a single page, even having one on top of the other.

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050927
Firefox/1.6a1 ID:2005092707
This bug can still be reproduced. Try on www.goowy.com

Comment 5

[Stephanie Daugherty [:sdaugherty]]

Confirming, but I'm not sure if this is an easy fix because the plugin takes the mouse events while it's in under the mouse.

Comment 8

[Aaron Slunt]

This is now a WFM Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008062219 (Gentoo) Firefox/3.0

Can any windows users verify if this is still an issue?

Comment 9

[Dan Weiss]

There were two separate bugs involving flash content.
One bug was that after you right clicked to open a context menu, the flash plugin got a series of invalid window messages which cause flash to receive random mouse movement to places in the flash, and also kept context menus open.  That bug was fixed.

There's also a different bug where if flash content uses 100% CPU usage, and you right click to bring up a context menu, Firefox stops responding.  That bug is still in Firefox 3.0, despite being marked as "duplicate" or "resolved".

Comment 10

[mmortal03]

I can still reproduce this.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1pre) Gecko/2008062706 GranParadiso/3.0.1pre ID:2008062706

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

If the plugin is windowed, we don't call nsWindow::DealWithPopups.

I think that we already hook the mouse events, however, we don't call it when plugin window has focus. So, we should call it at that time.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.1

Oops... Sorry for the spam.

Comment 15

[Ere Maijala (slow)]

Comment on attachment 344605 [details] [diff] [review]
Patch v1.1

Doesn't seem to fix the problem (at least for the page in the URL field). Am I missing something?

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v2.0

Right, my previous patch only works fine with windowed/windowless flash player.

The site of URL field uses Java. The window is created by Java, and it is another thread. Therefore, we don't hook the thread's message now.

This patch hooks all threads mouse messages. This works fine for me.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 347260 [details] [diff] [review]
Patch v2.0

This is not good approach.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v3.0

I think that this is better.

This patch doesn't change the hook spec. But when focus is gone to another thread window, the popup is rolled up. This behavior doesn't support software keyboard which steals focus from us. But we don't need to worry about it. Because we already don't support such software keyboard.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

+          // If the window is our window but the wndproc is not same as
+          // nsWindow's, the window is windowed plugin window. Then, the mouse
+          // events are not sent to us.
+          LONG proc = ::GetWindowLongW(ms->hwnd, GWL_WNDPROC);
+          if (proc != (LONG)&nsWindow::WindowProc)
+            ScheduleHookTimer(ms->hwnd, (UINT)wParam);

I don't like this much. It means that if someone tries to subclass one of our windows for some reason, there will be weird focus changes. I would rather mark widgets used for plugins with some kind of flag that we can test explicitly.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v4.0

ok.

This way is same as cocoa widget.

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 349373 [details] [diff] [review]
Patch v4.0

+  mIsPluginWindow     = 0;

PR_FALSE

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v4.1

Thank you, this patch should be landed after b2, maybe.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 349374 [details] [diff] [review]
Patch v4.1

a191=beltzner

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: hg bundle file

Comment 25

[Shawn Wilsher :sdwilsh]

http://hg.mozilla.org/mozilla-central/rev/3a11a901d758

Comment 26

[emmawebb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050927


translate spanish to english @ https://goo.gl/7T8JuZ

Comment 27

[paulkena]

Thank you, this patch should be landed after b2, maybe.
cắt tuyến mồ hôi nách @ http://benhhoinach.com/dia-chi-chua-hoi-nach/chua-hoi-nach-vien-108.html