mh_nichts Reporter
	Description • 9 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

I'm developing a website using Modernizr for touch detection.
1. Open the Responsive Design View
2. Click the button to enable Touch events and refresh the page as asked -> Touch events are detected, dom.w3c_touch_events.enabled has a value of "1"
3. Click the button to disable Touch events and refresh the page -> Touch events are still detected, dom.w3c_touch_events.enabled has still a value of "1".


Actual results:

After clicking the button to disable Touch events in the Responsive Design View, Touch events are still detected, dom.w3c_touch_events.enabled has still a value of "1".
This stays so even after closing the Responsive Design View.


Expected results:

Touch events shouldn't be detected anymore, dom.w3c_touch_events.enabled should get a value of "0".

	mh_nichts Reporter
	Comment 1 • 9 years ago

The thing is maybe not that simple.

Here is a test case, with Modernizr :
http://codepen.io/mh-nichts/pen/YXRwYv

After enabling once the Touch events via the Responsive Design View, the Touch events are always detected by Modernizr (hence the "touch" class on html), and dom.w3c_touch_events.enabled stays with a value of "1".

However, the "touchstart" event in itself is only fired when the Touch events are enabled via the button, but is not fired when the Touch is disabled via the button (even if dom.w3c_touch_events.enabled still has a value of "1" at that moment).

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 2 • 9 years ago

Are you able to reproduce this if you test in Nightly 43?  I just tried but for me, the about:config value was always reset.

If you can still reproduce, what is the **original** value of dom.w3c_touch_events.enabled on your machine?  Is it 0 or 2?

	Bob
	Comment 3 • 9 years ago

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2)
> Are you able to reproduce this if you test in Nightly 43?  I just tried but
> for me, the about:config value was always reset.
> 
> If you can still reproduce, what is the **original** value of
> dom.w3c_touch_events.enabled on your machine?  Is it 0 or 2?

I can reproduce. This occurs when original value of dom.w3c_touch_events.enabled is 1 -- but this actually can happen if you close the browser while Responsive Design View/Simulate Touch Events is enabled! In that case, dom.w3c_touch_events.enabled stays at 1 when the browser is closed and the correct original value is forgotten when the browser is re-opened - so Simulate Touch Events ends up toggling between 1 and 1.

I can reproduce this on current release (44.0), Aurora 46.0a2 (2016-02-03) and Nightly 47.0a1 (2016-02-03).

On a related note, due to how Simulate Touch Events currently works, turning it on both fires touch events on the tab it's enabled on and exposes (but does not fire) touch events on other tabs. This actually causes some webapps to detect (and switch into) a touch-enabled mode on those other tabs, despite touch events not working. Ideally, enabling Simulate Touch Events should have no side-effects outside the tab it's enabled on - which should also fix this bug.

	Bob
	Comment 4 • 9 years ago

Just to be clear, here's a STR:

1. Open browser (clean profile). Observe that dom.w3c_touch_events.enabled is set to 0 (or 2).
2. Open Responsive Design View.
3. Enable Simulate Touch Events. Observe that dom.w3c_touch_events.enabled is set to 1.
4. Close the browser (*without* turning off touch events/disabling RDV).
5. Open the browser again. Observe that dom.w3c_touch_events.enabled is still set to 1 (!).
6. Visit touch test page - touch will be detected (ontouchstart present) but touch events will never actually fire.
7. Open RDV, enable Simulate Touch Events. Now touch events fire correctly. Observe that dom.w3c_touch_events.enabled is still 1.
8. Disable Simulate Touch Events. Observe that dom.w3c_touch_events.enabled is *still* 1 (!!!). Touch events no longer fire, but ontouchstart is still detected.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 5 • 9 years ago

(In reply to Bob from comment #4)
> Just to be clear, here's a STR:
> 
> 1. Open browser (clean profile). Observe that dom.w3c_touch_events.enabled
> is set to 0 (or 2).
> 2. Open Responsive Design View.
> 3. Enable Simulate Touch Events. Observe that dom.w3c_touch_events.enabled
> is set to 1.
> 4. Close the browser (*without* turning off touch events/disabling RDV).
> 5. Open the browser again. Observe that dom.w3c_touch_events.enabled is
> still set to 1 (!).
> 6. Visit touch test page - touch will be detected (ontouchstart present) but
> touch events will never actually fire.
> 7. Open RDV, enable Simulate Touch Events. Now touch events fire correctly.
> Observe that dom.w3c_touch_events.enabled is still 1.
> 8. Disable Simulate Touch Events. Observe that dom.w3c_touch_events.enabled
> is *still* 1 (!!!). Touch events no longer fire, but ontouchstart is still
> detected.

Thanks for the detailed STR, that helps quite a lot!  It's true that we fail to reset the pref if you close the browser while RDM is open and touch enabled, so that would definitely trigger the problem.

Bug 970346 intends to add a per-tab API for controlling this, so that should resolve the problem here as well.  Let's depend on it for now.

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 6 • 8 years ago

The new RDM UI shipping in Firefox 52 only enables touch support per tab, so the about:config value is unmodified and this issue should not happen anymore.