Bug 56012 – [Qt] Touch Events are exposed to JavaScript even if there is no touch hardware

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore JavaScript

[Cédric Martin]

Since Qt4.6 (as far as I could read) Webcore is exposing touch events even if the device isn't a touch device.

It's is missleading javascript application to think they are on a touch device and disable standard events handler.

to reproduce the problem try to load the HelloWorld sample : http://code.google.com/intl/fr-FR/apis/maps/documentation/javascript/examples/map-simple.html
into a qwebview

the map will load with the mobile UI no mouse drag (pan) no mousewheel (zoom)

this is caused by a test made by the google api.

function gk(a,b){
var c=n[tb]("div");c[x](b,"return;");
return typeof c[b]=="function"||b in n[ji]
};

we have 
 var n = document;
 var tb = "createElement";
 var x = "setAttribute";
 var ji = "documentElement";

gk(qk,"ontouchstart"); // will always return true on Qtwebkit

the function create a div element assign "return;" to the ontouchstart event and check if the type of the returned object is function

it also check the property "ontouchstart" of document.documentElement 


it should be possible to not expose the touchevents (ontouchstart,ontouchmove,ontouchend) within the application

something like QWebSettings::globalSettings()->setAttribute(QWebSettings::TouchEnabled,true/false);


I guess not only google api is impacted other big JS libraries like Jquery/JQueryMobile/Modernizr should also be affected.

[Alexey Proskuryakov]

It's up to Qt folks to ultimately make a decision, but this is not really a bug in my opinion. Even if hardware has a touch screen, there is no guarantee that the user prefers touch interface. There are many devices that have both touchscreens and mouse-like input devices, so disabling mouse events when touch support is present is simply wrong.

I believe Google Chrome has it even worse - window.TouchEvent is exposed, but completely unimplemented.

[Cédric Martin]

Nope. I dont reproduce the problem with google chrome (10.0.648.127)
but maybe there is some hack(user-agent) somewhere.

Anyway Google or not google. ToucheEvents should not be exposed on a non touch device. and it's such a pain to re-compile Qtwebkit that it would be easier to let the developper do it at run time.

[Cédric Martin]

I agree it's not really a "bug" It's just an arbitrary decision that make life difficult to devs like me.

I didnt check statistics but I dont think touch devices are already majority in the device world. I guess this choice is due to convergence with other Nokia's project (Maemo etc...).

[Benjamin Poulain]

MeeGo and Windows 7 can have touch or not depending on the hardware. Touch is enabled by default, so it is exposed to JavaScript.

We want to enable or disable touch based on the hardware support but Qt does not provide such functionnality yet.

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.