Closed Bug 1161634 Opened 5 years ago Closed 5 years ago
Allow synthesizing native mouse wheel events on Linux
+++ 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.
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
Awaiting try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=dbc13893d1a1 with baited breath.
Attachment #8601668 - Flags: review?(karlt)
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]: ----------------------------------------------------------------- cool
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 https://treeherder.mozilla.org/logviewer.html#?job_id=9604133&repo=mozilla-inbound
So the test passes when run in isolation, in both e10s and non-e10s . It passes on non-e10s when run along with the rest of M-4 suite, but fails on e10s . 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).  https://treeherder.mozilla.org/#/jobs?repo=try&revision=08d95edf5cb3  https://treeherder.mozilla.org/#/jobs?repo=try&revision=26d5fb568ce9
Depends on: 1162600
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.
Depends on: 1163640
4 years ago
Depends on: 1272152
You need to log in before you can comment on or make changes to this bug.