Closed Bug 896017 Opened 6 years ago Closed 6 years ago

Defect - Errant mousemove event fires after a touchstart, triggering mouse input scrollbars on content

Categories

(Firefox for Metro Graveyard :: Input, defect, P2)

x86_64
Windows 8.1
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: jimm, Assigned: jimm)

References

Details

(Whiteboard: feature=defect c=tbd u=tbd p=1)

Attachments

(3 files, 1 obsolete file)

STR:

1) open a scrollable page
2) move the mouse to bring up scrollbars
3) drag the page using touch

result: sometimes mouse scrollbars will reappear after you touch the screen. The cuase is a mysterious mousemove that shows up after the first touchstart, triggering InputSourceHelper's precise input events.
Summary: Errant mousemove event fires after a touchstart, triggering mouse input scrollbars on content → Defect - Errant mousemove event fires after a touchstart, triggering mouse input scrollbars on content
Whiteboard: feature=defect c=tbd u=tbd p=0
(In reply to Brian R. Bondy [:bbondy] from comment #1)
> possibly bug 841228?

Thought of that too, but it isn't the cause. That triggers in OnTapped, and this event show up while you're still dragging the page around.

I think this is a fairly recent regression, it wasn't doing this when I worked on bug 888329. Working up a debug build so I can trap the event and get a good stack.
Weird, even in a debug build the stack here is completely hosed - 

 	xul.dll!NS_InvokeByIndex(nsISupports * that=0x0927fc00, unsigned int methodIndex=15, unsigned int paramCount=0, nsXPTCVariant * params=0x02c9de60) Line 71	C++
 	xul.dll!CallMethodHelper::Invoke() Line 2795	C++
 	xul.dll!CallMethodHelper::Call() Line 2133	C++
 	xul.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...}, XPCWrappedNative::CallMode mode=CALL_METHOD) Line 2099	C++
 	xul.dll!XPC_WN_CallMethod(JSContext * cx=0x04840070, unsigned int argc=0, JS::Value * vp=0x02c9e2b8) Line 1315	C++
 	mozjs.dll!js::CallJSNative(JSContext * cx=0x04840070, int (JSContext *, unsigned int, JS::Value *) * native=0x6bfb15e0, const JS::CallArgs & args={...}) Line 225	C++
 	mozjs.dll!js::Invoke(JSContext * cx=0x04840070, JS::CallArgs args={...}, js::MaybeConstruct construct=NO_CONSTRUCT) Line 477	C++
 	mozjs.dll!js::Invoke(JSContext * cx=0x04840070, const JS::Value & thisv={...}, const JS::Value & fval={...}, unsigned int argc=0, JS::Value * argv=0x02c9e42c, JS::MutableHandle<JS::Value> rval={...}) Line 527	C++
>	mozjs.dll!js::ion::DoCallFallback(JSContext * cx=0x04840070, js::ion::BaselineFrame * frame=0x02c9e454, js::ion::ICCall_Fallback * stub=0x09827688, unsigned int argc=0, JS::Value * vp=0x02c9e41c, JS::MutableHandle<JS::Value> res={...}) Line 6996	C++
 	03cc5af5()	Unknown
 	[Frames below may be incorrect and/or missing]	
 	09827688()	Unknown
 	04571180()	Unknown
 	04570b25()	Unknown
Ah, nm, that was due to the funky way I was trapping this. I have a better stack now.
Attached file stack.txt
Odd, this is coming from winrt.
Attached file strange.txt
Odd Win8 bug which must have come down in an update, this wasn't happening a few weeks ago. We can work around this in the front end. In fact there's another corner case (touch input while moving the mouse) that we can address at the same time. One concern I have is how this might impact content which also receives this weird mousemove event. If we need to we can filter this down in widget pretty easily.
My guess is ms will pick up on this bug and eventually fix it.
Attached patch patch (obsolete) — Splinter Review
Attachment #778845 - Flags: review?(mbrubeck)
Comment on attachment 778845 [details] [diff] [review]
patch

Review of attachment 778845 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/metro/base/content/input.js
@@ +1155,5 @@
>   * Helper to track when the user is using a precise pointing device (pen/mouse)
>   * versus an imprecise one (touch).
>   */
>  var InputSourceHelper = {
>    isPrecise: false,

You might want to add "touchisActive: false," here just to avoid possible undefined property warnings.

@@ +1186,5 @@
> +      this.touchIsActive = true;
> +      break;
> +      case "touchend":
> +      this.touchIsActive = false;
> +      break;

nit: please add an extra indentation level to these lines (except the "case" statements), for readability.
Attachment #778845 - Flags: review?(mbrubeck) → review+
Blocks: metrov1it11
Keywords: checkin-needed
Whiteboard: feature=defect c=tbd u=tbd p=0 → feature=defect c=tbd u=tbd p=1
No longer blocks: metrov1defect&change
Status: NEW → ASSIGNED
Priority: -- → P2
QA Contact: jbecerra
Attachment #778845 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/c0ae4eae38eb
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:25.0) Gecko/20100101 Firefox/25.0
Build ID: 20130805030205

WFM
Tested on Windows 8 for iteration-11 using latest nightly built from http://hg.mozilla.org/mozilla-central/rev/482b9d04974a

I followed steps provided in comment0 and got expected result.
I didn't see mouse scroll-bars reappeared after touching the screen.
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20130815030203
Built from http://hg.mozilla.org/mozilla-central/rev/a8daa428ccbc

WFM
Tested on windows 8 using latest nightly for iteration-12. Followed steps provided in comment0 and got expected result.
Status: RESOLVED → VERIFIED
Blocks: 922908
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.