Closed Bug 1217515 Opened 9 years ago Closed 9 years ago

dom.w3c.touch_events.enabled is 0 on GTK even though touch event support is now implemented

Categories

(Core :: Widget: Gtk, defect)

Product:
Core
Component:
Widget: Gtk
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla45
Tracking Flags:
Tracking Status
firefox44 --- affected
firefox45 --- fixed

People

(Reporter: overholt, Assigned: botond)

References

Details

Attachments

(1 file, 1 obsolete file)

MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc
40 bytes, text/x-review-board-request
roc
: review+
Details
I verified my nightly build includes the work in bug 978679 but I'm not getting touch events that can be used for scrolling (just mouse click-and-hold -type events). This is in both e10s and non-e10s windows.
FWIW I see that dom.w3c_touch_events.enabled is set to 0 and not 2 which the patch here seems to indicate it should be: https://hg.mozilla.org/mozilla-central/rev/cb6b065f2a23#l7.19
MOZ_USE_XINPUT2=1 ?
(In reply to Karl Tomlinson (ni?:karlt) from comment #2) > MOZ_USE_XINPUT2=1 ? I've tried with and without that environment variable. It doesn't work either way. I've tried various web pages.
Maybe Botond could look into this with you, since you're in the same office?
Flags: needinfo?(botond)
(In reply to Andrew Overholt [:overholt] from comment #1) > FWIW I see that dom.w3c_touch_events.enabled is set to 0 and not 2 which the > patch here seems to indicate it should be: > https://hg.mozilla.org/mozilla-central/rev/cb6b065f2a23#l7.19 If you change it to 2 does it work?
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5) > (In reply to Andrew Overholt [:overholt] from comment #1) > > FWIW I see that dom.w3c_touch_events.enabled is set to 0 and not 2 which the > > patch here seems to indicate it should be: > > https://hg.mozilla.org/mozilla-central/rev/cb6b065f2a23#l7.19 > > If you change it to 2 does it work? No.
Is it possible the machine that built the build you are using didn't have gtk3 and so all that code got #ifdef'd out?
(In reply to Kartikaya Gupta from comment #7) > Is it possible the machine that built the build you are using didn't have > gtk3 and so all that code got #ifdef'd out? If this was the case, wouldn't the build not use GTK+3 at all?
I'm not sure. Maybe I should stop guessing and let Botond investigate :)
I was just testing with a downloaded build. I'll do a local build and see if it's different.
I just pulled and built from m-c master and I *think* it was built against gtk3 (it's at least linked against it): $ ldd ../obj-x86_64-unknown-linux-gnu/dist/bin/libmozgtk.so |grep -i gtk libgtk-3.so.0 => /lib64/libgtk-3.so.0 (0x00007fc4c9778000) But |./mach run| still doesn't give me touch-enabled scrolling. I'll wait for Botond :)
(In reply to Andrew Overholt [:overholt] from comment #1) > FWIW I see that dom.w3c_touch_events.enabled is set to 0 and not 2 which the > patch here seems to indicate it should be: > https://hg.mozilla.org/mozilla-central/rev/cb6b065f2a23#l7.19 Ah, this is explained by the fact that browser/app/profile/firefox.js overrides all.js, and firefox.js sets it back to 0. So even on a good gtk3 build the pref will need to be set manually. Also I don't think the pref is live, it's read on widget creation only (at least for APZ purposes) so a restart is probably required after changing it.
I just tried it on my laptop, and it's not working for me, either, even after setting the pref to 2 and restarting. I will investigate.
Flags: needinfo?(botond)
It looks like the callback touch_event_cb gets registered, but is never called.
Ah, I wasn't running with MOZ_USE_XINPUT2=1 (see comment 2). You need that *and* dom.w3c.touch_events.enabled manually set to 2 (or 1) for touch events to work. With both of those in place, touch events work for both Andrew and me.
I'm going to repurpose this bug to fix the pref issue (so it really is set to 2 by default on GTK, like we intended). Disabling touch events in XInput2 is disabled is (for now) intentional (see bug 1170342 comment 12).
Summary: No touch events on Fedora 21 with a build including work from bug 978679 → dom.w3c.touch_events.enabled is 0 on GTK even though touch event support is now implemented
Assignee: nobody → botond
Bug 1217515 - Remove a pref entry in all.js that has no effect. r=roc The pref is overridden in firefox.js and b2g.js, which cover all platforms on which XP_WIN can be true, so no one sees the value set in all.js.
Attachment #8679064 - Flags: review?(roc)
Bug 1217515 - Set dom.w3c_touch_events.enabled for GTK3 in firefox.js instead of all.js. r=roc
Attachment #8679065 - Flags: review?(roc)
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc https://reviewboard.mozilla.org/r/23359/#review20803 I think it would be better to remove the setting of this pref from b2g.js and firefox.js, and just set it once in all.js. AFAIK there's no need to have per-application setting of this pref.
Attachment #8679064 - Flags: review?(roc)
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #19) > I think it would be better to remove the setting of this pref from b2g.js > and firefox.js, and just set it once in all.js. AFAIK there's no need to > have per-application setting of this pref. Different applications do different things, though: - b2g.js sets it to 1 - graphene.js sets it to 0 - mobile.js sets it to 1 - b2gdroid.js sets it to 1 - for tests we set it to 1 - for GTK3 we want it set to 2 - for other platforms (e.g. non-GTK3 desktop) we want it set to 0 It seems like expressing this through per-application settings is the cleanest.
Hi guys, I've just tried on my machine (with nightly and MOZ_USE_XINPUT2=1). Setting `dom.w3c.touch_events.enabled` to 2 doesn't work. Only setting `dom.w3c.touch_events.enabled` to 1 work. I'm on Ubuntu GNOME 15.10 (GNOME 3.16).
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc Adding back review flag as per comment 20.
Attachment #8679064 - Flags: review?(roc)
(In reply to Botond Ballo [:botond] from comment #20) > Different applications do different things, though: > > - b2g.js sets it to 1 > - graphene.js sets it to 0 > - mobile.js sets it to 1 > - b2gdroid.js sets it to 1 > - for tests we set it to 1 > - for GTK3 we want it set to 2 > - for other platforms (e.g. non-GTK3 desktop) we want it set to 0 True, but I still think that in most cases it doesn't make sense for these settings to be per-app. How about this: -- in all.js, set pref to 2 except on Mac/Windows make it 0 -- keep graphene.js setting at 0 -- keep tests setting at 1 -- remove settings in b2g.js, mobile.js, b2gdroid.js and make Android/Gonk autodetect just return "true". How does that sound?
Flags: needinfo?(botond)
Sounds good, thanks!
Flags: needinfo?(botond)
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc Review request updated; see interdiff: https://reviewboard.mozilla.org/r/23359/diff/1-2/
Attachment #8679064 - Attachment description: MozReview Request: Bug 1217515 - Remove a pref entry in all.js that has no effect. r=roc → MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc
Attachment #8679065 - Attachment is obsolete: true
Attachment #8679065 - Flags: review?(roc)
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc https://reviewboard.mozilla.org/r/23359/#review22509
Attachment #8679064 - Flags: review?(roc) → review+
I thought perhaps the problem was that that Mulet had touch-events disabled before because the firefox.js pref was overriding the b2g.js pref, and with my patch it was being enabled because the #ifdef MOZ_B2G was taking effect, but based on this Try push (which explicitly sets the pref to 0 in mulet.js), that's not the case: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a248647889ff I'll continue to investigate.
Flags: needinfo?(botond)
OK, turns out the problem was that some JS files used by B2G were testing for touch events being enabled by checking that the pref value is == 1, but the patch was changing the pref value to 2. Changing the checks to != 0 fixed this. https://treeherder.mozilla.org/#/jobs?repo=try&revision=c239ff4d23ab
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc Review request updated; see interdiff: https://reviewboard.mozilla.org/r/23359/diff/2-3/
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc Whoops, I didn't meant for MozReview to carry the r+ here.
Attachment #8679064 - Flags: review+ → review?(roc)
Comment on attachment 8679064 [details] MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc https://reviewboard.mozilla.org/r/23359/#review22879
https://hg.mozilla.org/mozilla-central/rev/abe200b244a5
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Depends on: 1227760
Depends on: 1246854
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: