User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce:

If firefox quantum 66.0.3 is executing a cpu intensive funtion(s) touch-action = "none" or pointer-events = "none" is ignored and the tab is zoomed in/out while pinching.

Actual results:

pinch to zoom changes the tab zoom level even if touch-action = "none" is set. Same for pointer-events = "none"

Expected results:

I want to force Firefox not to perform pinch gestures which lead to a change of the zoom of the current tab. I want to disable touch-events even when firefox does a CPU intensive calculation.

Hi @Idsse, please provide accurate steps, TC's and any other info in order to test the issue. You grab the issue from here? https://stackoverflow.com/questions/55907756/disable-touch-events-on-firefox-windows-tablet-doesnt-work-partially ?
Thanks.

Hi @ Liviu,
yes I have created the stackoverflow entry (before creating this bugentry).

Here I have created a fiddle where you can test the behaviour:
https://jsfiddle.net/hfa0w7p9/

I pinch to zoom on a windows tablet then on Edge or Chrome the pinch to zoom is ignored as stated in the css: touch-action: none.
But on firefox the browser zoom is changed.

I think its a firefox bug.

Thank you for debugging!

Hi @Idsse, tested the issue:
[Platform affected]: Windows 10 Surface Pen and Touch tablet
[Firefox versions]: release version 66.0.5, beta 67.0b19, latest nightly 68.0a1
The issue can be reproduced

Mention that before the issue happens in all Firefox versions a trigger announcing a script that slows down the page will be displayed - along with 2 buttons (can be seen at the attachments). By pressing "Stop it" the page can be zoomed without any issue. By pressing on "Wait it" after aprox. 1 minute, the zoom function can be used.

I will set a component for it and if isn't the proper one please fell free to change it.

Additionally, in other browsers, like Chrome the issue won't occur, moreover the yellow trigger isn't show up - no script to slow down any process.

Hi @Liviu,
thank you for testing and confirming.

I want to tell you, that in my real javascript application there does not show a popup which asks the user for waiting for finishing of the script. My real application has a shorter cpu calculation.
I will tell you what I want to achieve: When I zoom the page the canvas will be drawn again. While this operation I activate "touch-action; none" CSS. So the user has to wait for canvas redrawn. This works in Chrome and Edge. But in firefox the zoom level is changed despite of "touch-action: none" So my gui is destroyed.

Please notice: I want to DISABLE the zoom operation with "touch-action: none" while the browser is blocking. Do you have understand it excactly? Pinch to zoom must be tested in the fiddle in the "result"-frame because there is the div with "touch-action: none"...

Please understand that I don't want to share my real application here. But I can send you a message if you want.

Hi @Idsse, I understand.
Further, someone from dev team can give us a hand and then we come with a response.
Thanks for your contribution.

I turned your JSFiddle into a standalone page so it's a little easier to use. You have to click on the blockInput div to start the JS computation. When that happens the image stops animating and the eventually the prompt to stop scripts appears. However when I pinch zoom on a Windows 10 touch-enabled laptop I'm not able to reproduce the problem. Can you confirm you see the problem on this test page, just to eliminate any confounding factors from JSFiddle?

@Kartikaya Thank you for the test. You are right. On the standalone Page the zooming doesn't occur.
But in my application I have a gui.
It seems if its not the single element then the error occurs.

Please can you add some elements to the page so that there is menu for example and test again to reproduce the error which is shown in the fiddle? Thank you!

I'm not able to reproduce on the fiddle either, because as soon as the fiddle loads it hangs running the JS and the image doesn't even show up. So there's nothing for me to pinch on (and even if I do pinch anywhere I don't see any zooming).

Feel free to save my test page locally and add stuff to it until you can reproduce the issue with it, and then re-upload the modified version back to this bug. If you can make a standalone version on which the bug reproduces reliably I can take a look.

OK, I have created a fiddle which adopts my application a little bit better:
http://jsfiddle.net/preczo3y/8/

Please pinch to zoom the white quarter. On pinchend blockinput element should be visible. After the calculation and after a while (window.setTimeout) it is made invisible. So one could pinch the quarter again.
But the blocking of the pinch gesture doesn't work as expected. Sometimes the browser window is zoomed.

Please can you check?
I'm sorry for the fiddle. But perhaps you can turn into a standalone? Thank you very much!!!

Hi @Idsse, re-tested again the issue with the fiddle from comment 11. I'm also not able to reproduce the issue. Now in my end there is no differences between how this happens in FF or other browsers.

Hi @Liviu,
I have tested again and I can reproduce the issue. But you have to pinch very often -> pinch in / pinch out while the calculation is running.
In my real app the zoom changes very often. In this fiddle not so often, but it DOES.

Please can you test again? You have to pinch in / pinch out directly on the middle oft the quarter.

Thank you very much!

Should I make a screenrecording?

Please make a short video. Thanks

OHH, I forgot the blockInput div in the html in my example. Sorry for that.
Please see the updated fiddle:
jsfiddle.net/szjxbndw/4/

Please can you test again? Thank you!

Hi @Idsse, re-tested again:
[Platform affected]: Windows 10 Surface Pro Tablet
[FF versions affected]: release 67.0, beta 68.0b4, nightly 69.0a1 and I've tried also FF version 60.0 where the issue can be reproduced as well.
I could reproduce the issue. In some cases is needed to pinch more than 6,7 times. After that the quarter is zoomed then refresh of the page is needed. Sometimes after trying to decrease the zoom, the quarter disappears or imports the size of the <div>frame.

The priority flag is not set for this bug.
:kats, could you have a look please?

For more information, please visit auto_nag documentation.

P3 for now. Leaving needinfo on me to try repro'ing again and investigate if I can. Although I would do this much more readily if the test case were a standalone HTML page attached to this bug instead of a fiddle.

(In reply to Idsse from comment #11)

Please pinch to zoom the white quarter. On pinchend blockinput element should be visible. After the calculation and after a while (window.setTimeout) it is made invisible. So one could pinch the quarter again.

So for one thing, when I do this, sometimes the calculation starts before the blockinput element is even rendered, so the page just appears frozen for a while, before the spinner quickly appears and disappears. I think this is because you start the calculation with a setTimeout(,0) which is not guaranteed to run after the repaint that makes the blockinput visible (i.e. it might run before, and then it will block the spinner from getting drawn)

But the blocking of the pinch gesture doesn't work as expected. Sometimes the browser window is zoomed.

I'm still not able to reproduce this. I do see the browser window zoom change but it's always a result of pinching while the blockinput is not up. All pinches that occur while the spinner is visible or while the page is "frozen" (calculation runs before blockinput renders) seem to be getting correctly ignored for me.

OK, let's change the calculation command without setTimeout(,0)! Can you please test it?

For me your argumaentation is not convincingly. Chrome and Edge behave like intended. For me it is a Firefox bug. I cannot block input. Do you have a workaround. If not its a bug.

(In reply to Idsse from comment #20)

OK, let's change the calculation command without setTimeout(,0)! Can you please test it?

For me your argumaentation is not convincingly. Chrome and Edge behave like intended. For me it is a Firefox bug. I cannot block input. Do you have a workaround. If not its a bug.

My argumentation why there shouldn't be a browser zoom:
There are two scenarios:

1. blockinput div is active: touch-input none prevents zooming
2. blockinput div is not active: touch-input should be handled by hamer.js lib so no browser zooming should be done
   There is no state between!

(In reply to Idsse from comment #21)

2. blockinput div is not active: touch-input should be handled by hamer.js lib so no browser zooming should be done
   There is no state between!

In your example, the white square handles zooming, but the blue areas around it allow the browser to handle it.

Is this representative of your actual site? That is, in your actual site, is the custom zooming limited to a small element, while the areas around it allow the browser to handle the zoom?

@Botond: Thank you for the hint. You are right. In my app the handling has the whole area. So we should adopt the fiddle and add touch-action none to the blue area. I think this one liner can be done by the person who proves the bug?

Ok, here's a standalone testcase that was prepared with http://jsfiddle.net/szjxbndw/4/ as a starting point and adding touch-action:none to the blue area as well.

Steps to reproduce with this test case:

1. Scroll down to the blue area
2. Repeatedly pinch-zoom in and out on the blue and white areas

This does occasionally cause browser zoom to trigger for me. However, the rate of reproduction is very low, like one per 30-60 seconds of pinching.

@Botond Thank you very much. My app which I don't want to share has a very high rate of production. There is no stupid calculation but a lot of rendering to new canvas. I have to block user input after pinchend and while rendering.
It would be great if Firefox can behave like Chrome and Edge so my app would run fine!

(In reply to Idsse from comment #25)

Thank you very much. My app which I don't want to share has a very high rate of production. There is no stupid calculation but a lot of rendering to new canvas.

Yup, I understand that.

Do you have a theory for why your app triggers the problem more often than this testcase, or what sort of change we could make to this testcase to get it to trigger the problem more often?

It would make it significantly easier to investigate and fix this, if we could get the problem to trigger more often.

We could change the calculation to a real testcase. My app performs a lot of things and I think there are synchronous and asynchronous calls. If pinch to zoom and the calls are executed I can reproduce the browser zoom with two more pinch to zooms while blockinput div should block.
So do you have an idea what we can use instead of the simple calculation? In my app I never get the "waiting for script" alert...

My app is obfuscated. Would it help if I send a personal message with the link? I cannot offer a source map.

(In reply to Idsse from comment #28)

My app is obfuscated. Would it help if I send a personal message with the link? I cannot offer a source map.

Yes, please feel free to do that.

Updating bug description because Auto Nag was recognizing it as a task, not a defect.

Hello, I have tested my app with latest firefox 82.0.2 and the bug doesn't occur.
Then I have tested the fiddle and one should really pinch inside the blue and white area. The browser does not change the zoom level while pinching in and out constantly. So I want to say good work. Firefox behaves like other browsers now and in my opinion correct. I can use my app as intended. Thank you.

Thank you for letting us know! Closing this bug as a duplicate of the big that almost certainly fixed the problem.