bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

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

RESOLVED FIXED in Firefox 45

Status

()

Core
Widget: Gtk
RESOLVED FIXED
3 years ago
2 years ago

People

(Reporter: overholt, Assigned: botond)

Tracking

Trunk
mozilla45
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox44 affected, firefox45 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

3 years ago
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.
(Reporter)

Comment 1

3 years ago
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 ?
(Reporter)

Comment 3

3 years ago
(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?
(Reporter)

Comment 6

3 years ago
(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 :)
(Reporter)

Comment 10

3 years ago
I was just testing with a downloaded build.  I'll do a local build and see if it's different.
(Reporter)

Comment 11

3 years ago
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.
(Assignee)

Comment 13

3 years ago
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)
(Assignee)

Comment 14

3 years ago
It looks like the callback touch_event_cb gets registered, but is never called.
(Assignee)

Comment 15

3 years ago
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.
(Assignee)

Comment 16

3 years ago
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)

Updated

3 years ago
Assignee: nobody → botond
(Assignee)

Comment 17

3 years ago
Created attachment 8679064 [details]
MozReview Request: Bug 1217515 - Clean up the way touch event support is configured. r=roc

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)
(Assignee)

Comment 18

3 years ago
Created attachment 8679065 [details]
MozReview Request: Bug 1217515 - Set dom.w3c_touch_events.enabled for GTK3 in firefox.js instead of all.js. r=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)
(Assignee)

Comment 20

3 years ago
(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.

Comment 21

3 years ago
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 21 is being tracked over in bug 1213342.
See Also: → bug 1213342
(Assignee)

Comment 23

3 years ago
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)
(Assignee)

Comment 25

3 years ago
Sounds good, thanks!
Flags: needinfo?(botond)
(Assignee)

Comment 26

3 years ago
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
(Assignee)

Updated

3 years ago
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+
Looks like the mulet gij test failures could be yours, too: https://treeherder.mozilla.org/logviewer.html#?job_id=17249068&repo=mozilla-inbound
(Assignee)

Comment 32

3 years ago
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)
(Assignee)

Comment 33

3 years ago
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
(Assignee)

Comment 34

3 years ago
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/
(Assignee)

Comment 35

3 years ago
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

Comment 38

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/abe200b244a5
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45

Updated

3 years ago
Depends on: 1227760
Depends on: 1246854
You need to log in before you can comment on or make changes to this bug.