User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

I'm trying to capture touch events in an early phase.

1. I open FF desktop in touch mode.
2. I run my code (attached sample page).
3. Swipe from left to right (touch and move).

Actual results:

Swipe is not registered.

Expected results:

Swipe should be registered. It works fine in Chrome (tested with 73.0).

This is the crucial part of the code:

			container.addEventListener('touchstart', (e) => {
				//console.log('touchstart', e);
				this.handleStart(e);
				e.preventDefault();
				e.stopImmediatePropagation();
				return true;
			}, {passive: false, capture: true});

Inside the handleStart function I use event.touches[0] which seem to be undefined in there.

Note! Everything works fine once I uncomment the console.log line. So it magically works when I use the event object before going into the handler.

No idea what happens... Seem like an optimization error to me.

Hi Maciej Jaros, I've tested this issue on Surface Pro 2 with Windows 10 using Firefox Nightly 68.0a1(2019-05-14) and I can't reproduce the issue, all my actions are recorded in the logs, please see the attached file.

Please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

I've tested on Nightly and the workaround is not working there.

I probably wasn't clear -- I meant that I'm testing on desktop with dev tools emulating touch. Not an actual touch screen.

Tests on FF nightly (notice active hand icon for emulating touch). This the attached test with console.log. Notice how touch events are actually undefined now (which is worse then in previous FF).

Similar test for Chrome shows correct logs.

A bit simplified code of the test.

Note that the problem might be just with how emulation works.

(In reply to Maciej Jaros from comment #2)

I've tested on Nightly <del>and the workaround is not working there</del>.

I probably wasn't clear -- I meant that I'm testing on desktop with dev tools emulating touch. Not an actual touch screen.

Sorry, cache... The workaround is working.

Just to be clear. This is working (has console.log with e exposed):

	initEvents(container) {
		container.addEventListener('touchstart', (e) => {
			console.log('touchstart', e);
			this.handleStart(e);
			e.preventDefault();
			e.stopImmediatePropagation();
			return true;
		}, {passive: false, capture: true});
		container.addEventListener('touchmove', (e) => {
			console.log('touchmove', e);
			this.handleMove(e);
			e.preventDefault();
			e.stopImmediatePropagation();
			return true;
		}, {passive: false, capture: true});
	}

This is not working (this is from swipe-test.zip):

	initEvents(container) {
		container.addEventListener('touchstart', (e) => {
			//console.log('touchstart', e);
			this.handleStart(e);
			e.preventDefault();
			e.stopImmediatePropagation();
			return true;
		}, {passive: false, capture: true});
		container.addEventListener('touchmove', (e) => {
			//console.log('touchmove', e);
			this.handleMove(e);
			e.preventDefault();
			e.stopImmediatePropagation();
			return true;
		}, {passive: false, capture: true});
	}

As it seems more like an issue in dev tool emulation, I am moving the issue to that component. Hopefully I got the component right.

Thanks for submitting this issue. I tried out your described test case and can confirm the touch events are undefined when console.log isn't used.

We can reproduce this problem in Mapbox GL JS. See https://github.com/mapbox/mapbox-gl-js/issues/8877 for further discussion on our side.

(In reply to Micah Tigley [:mtigley] from comment #10)

It seems like the refactoring in Comment 9 fixes this issue (yay!) and also Bug 1549220. I'll clean-up this patch and get it ready for a review.

Micah, can this now be closed per the above comment from bug 1588438?

(In reply to Panos Astithas (he/him) [:past] (please ni?) from comment #10)

(In reply to Micah Tigley [:mtigley] from comment #10)

It seems like the refactoring in Comment 9 fixes this issue (yay!) and also Bug 1549220. I'll clean-up this patch and get it ready for a review.

Micah, can this now be closed per the above comment from bug 1588438?

Yes, we can close this now. Thank you for following up on this.