phantomjs pretends to be a touch browser

[ariya]

brian.bu...@gmail.com commented:

Which version of PhantomJS are you using? 1.4.1

What steps will reproduce the problem?

Run this phantomjs script:

var page = new WebPage();

page.open('http://modernizr.github.com/Modernizr/touch.html', function(status) {
page.render("output.png");
phantom.exit(0);
});

What is the expected output? What do you see instead?

Expected:

Modernizr should not detect PhantomJS as a touch browser.
document.documentElement.ontouchstart (etc.) should be undefined

Actual:

Modernizr is detecting PhantomJS as a touch browser because it appears to implement several touch events.

Which operating system are you using?

Mac OS X 10.7

Did you use binary PhantomJS or did you compile it from source?

Binary

Please provide any additional information below.

Perhaps phantomjs should accept a configuration option to select whether it emulates a mouse browser or a touch browser. Currently, it seems that it pretends to be both, and this breaks Highcharts.js mouseover events / tooltips, because highcharts detects a touch browser and disables the mouse events.

Disclaimer:
This issue was migrated on 2013-03-15 from the project's former issue tracker on Google Code, Issue #375.
🌟   20 people had starred this issue at the time of migration.

[ariya]

downch...@gmail.com commented:

Are you sure this isn't an upstream webkit issue? WebKit has touch objects in it in the desktop versions (unfortunately).

[ariya]

brian.bu...@gmail.com commented:

document.documentElement.ontouchstart is not defined in Chrome or Safari, so Modernizr, Highcharts, etc. correctly treat them as desktop browsers instead of touch browsers. Maybe they explicitly remove/disable the touch objects?

[buymeasoda]

I ran into this issue as well, using PhantomJS 1.7.

It appears to expose events that mobile WebKit supports but are not exposed via other desktop webkit browser like Chrome and Safari.

For example, the following JavaScript feature detect:

'ontouchstart' in window;

Returns true for PhantomJS (and iOS), but false for Chrome (v24 dev) and Safari (6).

I had some UI widget JavaScript tests failing in only the iOS simulator and PhantomJS, which wasn't such a bad thing ;) but my assumption was that Phantom would fulfill the role of a headless desktop browser and mirror behavior of browsers like Chrome and Safari.

On a side note, if there ever was a "PhantomJS Mobile", that would be great ;)

[ghost]

lmjab...@gmail.com commented:

Ran into this issue as well, can we escalate this to high priority?

[ariya]

r...@electronicinsight.com commented:

Would love to take the user-agent "casperjs" hacks out of my codebase!

[vitallium]

vitaliy....@gmail.com commented:

Actually, I can fix this issue by disabling mobile features. But, I want to achieve as much as possible from this issue. If we had a command like '-enable-mobile-features', it would be a huge improvement for PhantomJS as headless browser.

[Havelock-Vetinari]

julian.s...@gmail.com commented:

It also adds touch class to html element which it is often used to determinate touch capable browsers. This kind of switch or even runtime option would be great.

[Havelock-Vetinari]

julian.s...@gmail.com commented:

Since I didn't find way to disable touch events on runtime, I have managed to compile phantomjs with webkit with disabled touch events
Simple command:
./build.sh --confirm --jobs 8 --qt-config "-D ENABLE_TOUCH_EVENTS=0"
Is not enough since there is a nasty bug in generated JSDocument.* files. Not all references to touch events are in conditionally compiled

I have attached simple patch for this issue. I can make a pull request if you are interested: Havelock-Vetinari@6aceaf6

[vitallium]

vitaliy....@gmail.com commented:

Yep, the attached patch will fix the issue. Pull requests are always welcome!

[Havelock-Vetinari]

julian.s...@gmail.com commented:

Pull request sent #408

[ariya]

ariya.hi...@gmail.com commented:

After some careful thought, I don't think I'll land the provided patch (#408). The reason is that the generated files should not be modified. They are generated as the WebKit module is imported into Qt source tree via an import script. Touching any of the generated files like that is troublesome for reasons (1) unnecessary diff with upstream QtWebKit (2) unknown regression state since we don't run the comprehensive WebKit layout tests (we just consume what's in QtWebKit).

If there is a demand to keep the build option around, I can definitely keep it as an unofficial patch, probably under patches/, for those who need it.

[Havelock-Vetinari]

julian.s...@gmail.com commented:

So this is more like WebKit bug in generated files. Is there any way to properly hook into or fix source generating mechanism?

[Havelock-Vetinari]

julian.s...@gmail.com commented:

Proper touch feature reporting by phantomjs is critical when it comes to testing complex layouts which change they features based on browser capabilities.

[ariya]

ariya.hi...@gmail.com commented:

There is no WebKit bug at all. As I mentioned earlier, the generated files may look different (at the generation time) depending on the feature sets enabled at that time. Modifying the generated file is not the correct thing to do.

Having a different feature set is possible by using the import script (see my post on the mailing-list about qt4-retrofit). However, unless this is accompanied by running WebKit layout tests with that particular set, we can never say whether there will be a regression or not.

[ariya]

ariya.hi...@gmail.com commented:

Also, I don't disagree that enabling or disabling touch support is a good idea. However, I think it's not technically possible right now with the current limitations.

[Havelock-Vetinari]

julian.s...@gmail.com commented:

Well, I consider missing preprocessors TOUCH_EVENT compile conditions as bug, since they are present in several parts of generated code, but not in all required places (so build fails).

[ariya]

ariya.hi...@gmail.com commented:

I see what you mean, it's about ENABLE(TOUCH_EVENTS) isn't? Well, we can look at the trunk WebKit IDL file and see if that gets fixed. In all cases, the binding needs to be modified so that the generated files are updated accordingly.

[Havelock-Vetinari]

julian.s...@gmail.com commented:

Yes, ENABLE(TOUCH_EVENT) is not fully handled. Simple --qt-config "-D ENABLE_TOUCH_EVENTS=0" fails since not all touch related JSDocument methods are in proper preprocessor directives.

[voelzmo]

So we just ran into this problem as well. Do I understand the problem correctly that the reporting whether touch events are supported or not is decided during compile time of webkit and that this makes a runtime switch such as --disable-touch impossible?

[mathiasschopmans]

As a workaround you can detect the phantomjs browser and disable the touch test:

if ('callPhantom' in window) {
  Modernizr.touch = false;
}

[robdefeo]

If I dont have control over the website, how can I disable touch as far as modernizr is concerned, is the only option to recompile? This would mean I would need two different binaries for different websites, one touch and one not?

[reidcooper]

I would love to be able to optionally stub out the touchevents/touch to return true or false, to my liking for my Rspec feature specs.

[prahladyeri]

Needs this to be resolved.

[vitallium]

Starting from 2.5 version PhantomJS no more pretends itself as a browser with touch events support.

[karthik289]

Can any one provide 2.1.1 version for Ubuntu 14.04 which is disabled the touch events.