Closed Bug 1161634 Opened 5 years ago Closed 5 years ago

Allow synthesizing native mouse wheel events on Linux


(Core :: Widget: Gtk, defect)

Gonk (Firefox OS)
Not set



Tracking Status
firefox41 --- fixed


(Reporter: kats, Assigned: kats)




(2 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #1161206 +++

In order to properly exercise the APZ code we need to be able to synthesize and dispatch native events on desktop platforms. The stubs for these already exist (see nsIDOMWindowUtils::sendNative*) but they are not implemented across all platforms. This bug is specifically about implementing SynthesizeNativeMouseScrollEvent on GTK.
Attached patch Patch (obsolete) — Splinter Review
The synthesization works, but the test actually fails *without* APZ because the preventDefault on the wheel event is getting ignored or something. Need to investigate more.
Assignee: nobody → bugmail.mozilla
Comment on attachment 8601669 [details] [diff] [review]
Part 2 - Update test to run on linux

Try is green (I know it doesn't look like it, but it's true! M-4 is where the test is, all the other chunks are empty because I used --tag in the try syntax, and get detected as failing).
Attachment #8601669 - Flags: review?(mstange)
Comment on attachment 8601669 [details] [diff] [review]
Part 2 - Update test to run on linux

Review of attachment 8601669 [details] [diff] [review]:

Attachment #8601669 - Flags: review?(mstange) → review+
Comment on attachment 8601668 [details] [diff] [review]
Part 1 - Implement native wheel event synth on gtk

>+  AutoObserverNotifier notifier(aObserver, "mousescrollevent");

I don't know the purpose of this.
Don't is matter that Observe() is called before the GdkEvent is actually processed?
Attachment #8601668 - Flags: review?(karlt) → review+
(In reply to Karl Tomlinson (ni?:karlt) from comment #6)
> I don't know the purpose of this.
> Don't is matter that Observe() is called before the GdkEvent is actually
> processed?

It's basically a ping back to the caller to indicate that the synthesization function has run. We need it because it run asynchronously from the call to nsIDOMWindowUtils::sendNative*Event. (That, in turn, was done so that the e10s and non-e10s cases would behave the same, since the e10s cases would necessarily be async across the IPC bridge). And no, in general we can't track these events "through" the OS layer so the Observe() just reports that the widget did the synthesization as requested. The caller can listen for the actual gecko event if they want to make sure it got created (and in fact that's what I do in the test).
sorry had to back this out for test failures like
Flags: needinfo?(bugmail.mozilla)
So the test passes when run in isolation, in both e10s and non-e10s [1]. It passes on non-e10s when run along with the rest of M-4 suite, but fails on e10s [2]. Therefore some other test in M-4 suite is interfering with this test, causing it to fail, in e10s mode.

What's annoying is that when I run the tests locally they pass always. (Also, running --total-chunks 5 --this-chunk 4 locally runs a different set of tests than on tryserver; I have to use --total-chunks 9 --this-chunk 8 to get approximately the same set of tests, and even then it's not perfect).

Flags: needinfo?(bugmail.mozilla)
Soo... I got a loaner and was able to reproduce the failure. Then I did some bisection attempts by playing with --total-chunks and --this-chunk and narrowed it down. At some point the test started passing, but it was also the first test in the chunk at that point. So then I tried shifting the chunks and widening the range again to try and narrow down a good vs bad range, and now I can't reproduce the failure at all, even with the original arguments that could reproduce them. *sigh*
After rebooting the loaner instance I was able to reproduce the problem again. After fiddling with the chunks some more I narrowed it down to the libeditor tests (I learnt that tests from a single folder never get split across chunks) so after that I had to start commenting out tests. I seem to have narrowed it down to test_bug417418.html in the libeditor mochitest suite. If I disable that test things pass.

Looking at the test the likely problem is that it synthesizes a bunch of mousedown events without the corresponding mouse-up events, causing the widget to enter a drag state and screwing up future tests.
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
See Also: → 1177233
You need to log in before you can comment on or make changes to this bug.