Closed Bug 561495 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Widget: Win32, defect)

1.9.2 Branch
x86
Windows Vista
defect
Not set

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .4+
status1.9.2 --- .4-fixed

People

(Reporter: poisondart00, Assigned: jimm)

References

()

Details

(Keywords: hang, regression, verified1.9.2)

Attachments

(2 files, 2 obsolete files)

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.
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
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.
Blocks: 552163
Component: General → Widget: Win32
Keywords: hang, regression
Product: Firefox → Core
QA Contact: general → win32
Summary: If you try scrolling in/out on the map you will get a crash, before i upgraded it worked fine. → If you try scrolling in/out on the map you will get a hang, before i upgraded it worked fine.
Version: unspecified → 1.9.2 Branch
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Ria: Why is this bug related to bug 552163? Looks like the map doesn't take any reaction for turning mouse wheel.
(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.
ok, I can reproduce this bug on my notebook. I'll check it.
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.
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)
Attached patch reply to mouse wheel v.1 (obsolete) — Splinter Review
This also adds the horizontal mouse wheel event, which should have been included in the patch for bug 561117.
Assignee: nobody → jmathies
Attachment #441366 - Flags: review?(masayuki)
Blocks: OOPP
This should probably block 1.9.2.4.
blocking1.9.2: --- → ?
Attached file hang stacks
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.
Attached patch reply to mouse wheel v.2 (obsolete) — Splinter Review
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?
Attachment #441366 - Attachment is obsolete: true
Attachment #441398 - Flags: review?(masayuki)
Attachment #441366 - Flags: review?(masayuki)
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!
Attachment #441398 - Flags: review?(masayuki) → review+
Attached patch updated patchSplinter Review
the tree is totally hosed this am, will get this in as soon as things clear up.
http://hg.mozilla.org/mozilla-central/rev/80c33f7a5a80
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Attachment #441398 - Attachment is obsolete: true
Attachment #441478 - Flags: review+
Attachment #441478 - Flags: approval1.9.2.4?
blocking1.9.2: ? → .4+
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
Attachment #441478 - Flags: approval1.9.2.4? → approval1.9.2.4+
Juan, can you verify this tomorrow with the nightly build since you have a scroll mouse there?
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.
Keywords: verified1.9.2
Duplicate of this bug: 547136
You need to log in before you can comment on or make changes to this bug.