FastClick and navigation to new window

[sharpeye-too]

I followed the steps to use FastClick with my jQuery code. Now it seems that links which were intended to open the target in a NEW WINDOW do not do so - on touch-screen devices like iPad. What happens is that the target page opens in the current window. Can this effect of FastClick be "commented-out" in the FastClick js?

[sharpeye-too]

I have discovered a way to correct this - namely by using the javascript version of the code to instantiate FastClick :

window.addEventListener('load', function() { FastClick.attach(document.body); }, false);

• instead of the jQuery version :

$(function() { FastClick.attach(document.body); });

I don't know why this change worked, but it did.

[sharpeye-too]

Now it seems that the reason the problem has gone away is that changing the code as in the previous comment has DISABLED FastClick. Touchscreen taps are sluggish again, as they were without FastClick. So I'm back to square one - the issue (or question) remains.

[mgustafsson1]

Sounds like if this is related to https://github.com/ftlabs/fastclick/issues/268

[sharpeye-too]

Thanks for the suggestion mgustafsson1. After briefly reviewing #268, I'll have to study that issue in more detail to see if there's a relation. Perhaps I wasn't clear enough with the exposition. My javascipt/jQuery code foresees two scenarios when a link to another page within the site is activated: (1) open the new page in the same window; and (2) open the new page in a new window (or tab). Essentially there is a flag which determines which of the two happens. If a sound track is playing, utilizing a player embedded in the first page, a new window (or tab) opens, and the sound track from the first page continues while the user peruses the new page. Depending on which link was activated, the new page might or might not have a player of its own. If a sound track in the new page is played, utilizing the identical player embedded in it, control parameters with the help of a session-cookie pause the first player when the new one starts playing ( - for what it's worth, not when the track starts loading). Going back to the first window, "unpausing" or resuming play of the first player where it was "remotely" paused by the second player causes the second player in turn to go into pause mode. This behavior continues with a theoretically unlimited number of windows within the same website, so that at any time only one player is playing. (Since this behavior is controlled by the session cookie, audio from sources other than the subject website is outside the loop and can play in parallel to the extent the device allows it). The problem I am having with FastTrack is that the "new window" scenario does not occur. Instead, the new page always opens in the same window, and if there is a sound track playing it stops abruptly before the new page loads. Also, because the first page is overwritten with the new page, none of various control parameters associated with the status of the player embedded in the first page are retained.

[amigo237]

@sharpeye-too I also have this problem. Do you have any solution?