Closed
Bug 561495
Opened 15 years ago
Closed 15 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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: poisondart00, Assigned: jimm)
References
()
Details
(Keywords: hang, regression, verified1.9.2)
Attachments
(2 files, 2 obsolete files)
3.90 KB,
text/plain
|
Details | |
2.91 KB,
patch
|
jimm
:
review+
beltzner
:
approval1.9.2.4+
|
Details | Diff | Splinter Review |
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•15 years ago
|
||
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•15 years ago
|
||
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
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•15 years ago
|
||
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•15 years ago
|
||
Ria: Why is this bug related to bug 552163? Looks like the map doesn't take any reaction for turning mouse wheel.
Comment 5•15 years ago
|
||
(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•15 years ago
|
||
ok, I can reproduce this bug on my notebook. I'll check it.
Comment 7•15 years ago
|
||
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.
![]() |
Assignee | |
Comment 8•15 years ago
|
||
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)
![]() |
Assignee | |
Comment 9•15 years ago
|
||
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)
![]() |
Assignee | |
Comment 11•15 years ago
|
||
Comment 12•15 years ago
|
||
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.
![]() |
Assignee | |
Comment 13•15 years ago
|
||
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 14•15 years ago
|
||
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+
![]() |
Assignee | |
Comment 15•15 years ago
|
||
![]() |
Assignee | |
Comment 16•15 years ago
|
||
the tree is totally hosed this am, will get this in as soon as things clear up.
![]() |
Assignee | |
Comment 17•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
![]() |
Assignee | |
Updated•15 years ago
|
Attachment #441398 -
Attachment is obsolete: true
![]() |
Assignee | |
Updated•15 years ago
|
Attachment #441478 -
Flags: review+
Attachment #441478 -
Flags: approval1.9.2.4?
Updated•15 years ago
|
blocking1.9.2: ? → .4+
Comment 18•15 years ago
|
||
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+
Comment 19•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/5481c3a1d81e
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/75333bb8bac3
status1.9.2:
--- → .4-fixed
Comment 20•15 years ago
|
||
Juan, can you verify this tomorrow with the nightly build since you have a scroll mouse there?
Comment 21•15 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•