561495 - If you try scrolling in/out on the map you will get a hang, before i upgraded it worked fine.

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Erick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100413 Firefox/3.6.4 (.NET CLR 3.5.30729)

If you try scrolling in/out on the map you will get a crash, before i upgraded it worked fine.

Reproducible: Always

Steps to Reproduce:
1.use the url i provided, let it load.
2.scroll in/out on the map
3.
Actual Results:  
FF crashes, im not sure if it is other platforms.

Expected Results:  
The map should zoom in/out.

Comment 1

[Tim (fmdeveloper)]

1) What version of Flash are you running? http://www.adobe.com/software/flash/about/

2) Does the crash still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode

3) Please provide a crash id or stacktrace -> https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report

Comment 2

[Ria Klaassen (not reading all bugmail)]

Confirmed with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre

It is a hang (low CPU), and in Firefox 3.6 it happens with IPC enabled and disabled. With trunk it only happens with IPC to true.

To reproduce the hang, you need to scroll over the plugin without clicking in it. So it is a kind of focus problem.

This hang is caused by Bug 552163.

Comment 3

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

I cannot reproduce this on Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100424 Minefield/3.7a5pre.

Comment 4

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

Ria: Why is this bug related to bug 552163? Looks like the map doesn't take any reaction for turning mouse wheel.

Comment 5

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)
> Ria: Why is this bug related to bug 552163? Looks like the map doesn't take any
> reaction for turning mouse wheel.

Rechecked, and this is the range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ae0999d2502&tochange=3bcd237e52a6 
so I thought bug 552163 seemed a good culprit to me.

STR:

- go to http://www.weather.com/outlook/homeandgarden/home/map/interactive/USNY0693?zoom=8&interactiveMapLayer=radar&from=today_media_map
- as soon as the page draws start scrolling with your wheel, without clicking anywhere

As soon as the mouse is above the flash, the plugin stops loading (if it still wasn't ready loading) and the cursor doesn't move anymore, if you move the mouse outside the window the cursor comes back as an hourglass.

I'm using a hid compliant mouse from Microsoft.

Comment 6

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

ok, I can reproduce this bug on my notebook. I'll check it.

Comment 7

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

Looks strange... The focused window (our content window) receives WM_MOUSEWHEEL first. It sends the message to plug-in window (another process). Then, deadlocked (looks our plug-in window doesn't re-receive the wheel message).

Seems that the plug-in access to our process at WM_MOUSEWHEEL handling. But I have no actual idea for the reason.

Comment 8

[Jim Mathies [:jimm]]

Confirmed here. All I had to do was open the page, place the cursor over the Bing map, and scroll. The browser locks up.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100425 Firefox/3.6.4 (.NET CLR 3.5.30729)

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.5pre) Gecko/20100425 Firefox/3.6.4 (.NET CLR 3.5.30729)

Comment 9

[Jim Mathies [:jimm]]

Attachment: reply to mouse wheel v.1

This also adds the horizontal mouse wheel event, which should have been included in the patch for bug 561117.

Comment 10

[Jim Mathies [:jimm]]

This should probably block 1.9.2.4.

Comment 11

[Jim Mathies [:jimm]]

Attachment: hang stacks

Comment 12

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

Comment on attachment 441366 [details] [diff] [review]
reply to mouse wheel v.1

I tested the patch. Basically, it's ok for me. But there is an issue, that is WM_*SCROLL messages. They are sent by some mouse drivers, e.g., TrackPoint of Thinkpad, see bug 539672.

When the lParam of the messages is not zero, we treat the messages as mouse wheel scrolling message. I.e., they are sent to plug-in window.  So, they also cause this bug. If PluginInstanceChild::PluginWindowProc() isn't called when the descendant window receives the messages, we can add them to here simply.  Otherwise, we shouldn't send WM_*SCROLL to plug-in window but it causes regression for such mouse users.  If we can send WM_MOUSE*WHEEL messages when we receives WM_*SCROLL, we should do it because it's better.

Comment 13

[Jim Mathies [:jimm]]

Attachment: reply to mouse wheel v.2

Masayuki, I've added those two to the child side sub class. I'm not sure from your description if they would also be needed on the parent side? Sounds like we send these from parent to child due to our custom handling of broken mouse drivers? Is this correct?

Comment 14

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

Comment on attachment 441398 [details] [diff] [review]
reply to mouse wheel v.2

> Masayuki, I've added those two to the child side sub class. I'm not sure from
> your description if they would also be needed on the parent side? 

Yes, with the parent side change r=masayuki.

> Sounds like
> we send these from parent to child due to our custom handling of broken mouse
> drivers? Is this correct?

Yes. This isn't good thing but we should emulate the mouse driver's behavior for plug-ins.

Thank you for your work!

Comment 15

[Jim Mathies [:jimm]]

Attachment: updated patch

Comment 16

[Jim Mathies [:jimm]]

the tree is totally hosed this am, will get this in as soon as things clear up.

Comment 17

[Jim Mathies [:jimm]]

http://hg.mozilla.org/mozilla-central/rev/80c33f7a5a80

Comment 18

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

Comment on attachment 441478 [details] [diff] [review]
updated patch

a=beltzner, please land on mozilla 1.9.2 default AND
mozilla-1.9.2 GECKO1924_20100413_RELBRANCH

Comment 19

[Benjamin Smedberg]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5481c3a1d81e
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/75333bb8bac3

Comment 20

[Al Billings [:abillings - ex-MoCo]]

Juan, can you verify this tomorrow with the nightly build since you have a scroll mouse there?

Comment 21

[juan becerra [:juanb]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.5pre) Gecko/20100427 Namoroka/3.6.5pre (.NET CLR 3.5.30729)

In 3.6.4 I could see the hang in Win7 and Vista, but I can mouse-scroll in the nightly just fine with no hang. It works in the trunk nightly as well.