Capturing touch events not working without log
Categories
(DevTools :: Responsive Design Mode, defect, P3)
Tracking
(Not tracked)
People
(Reporter: egil, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [rdm-reserve])
Attachments
(4 files, 1 obsolete file)
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.
- I open FF desktop in touch mode.
- I run my code (attached sample page).
- 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.
Comment 1•5 years ago
|
||
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.
Reporter | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Comment 3•5 years ago
|
||
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).
Reporter | ||
Comment 4•5 years ago
|
||
Similar test for Chrome shows correct logs.
Reporter | ||
Comment 5•5 years ago
|
||
A bit simplified code of the test.
Note that the problem might be just with how emulation works.
Reporter | ||
Comment 6•5 years ago
|
||
(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});
}
Updated•5 years ago
|
Comment 7•5 years ago
|
||
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.
Comment 8•5 years ago
|
||
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.
Updated•5 years ago
|
Comment 9•5 years ago
|
||
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.
Comment 10•5 years ago
|
||
(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?
Comment 11•5 years ago
|
||
(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.
Description
•