Twitter.events.bind follow not firing on mobile web browser

[marcusjlmccoy]

I have a website that most people will only access via their mobile device. I would like to track who follows by clicking on the follow us button, but for some reason it is not working the bind tweet works. What the bind tweet does is opens another window on the mobile device, requires person to hit the tweet button again but once the tweet is sent, that window automatically closes and goes back to my websites and fires the handler. Here is my website: http://www.idc1.co/. Whats interesting is that everything works fine on a desktop browser. Can you look into this.

[benward]

Hi Marcus,

This is a known and temporary issue.

Basically, there’s a verrrrrry long running limitation on Twitter that when people are logged into the mobile website, they don’t get logged into Web Intents, and vice versa. Because that user experience of entering passwords on mobile is incredibly annoying, we want to minimise that. Pending the full solution, we’ve directed the user intent on mobile to the actual mobile website profile, to the end that you should get more people actually following you because they won’t have to sign in. This has the side affect that our mobile site doesn’t implement Intent Events, so they’re not being fired back to your page.

Would love to get a sense of how severe an inconvenience this is for you; I know there have been a few threads about it on here over the past couple of weeks. There’s a lot of work in play that will bring it all back together, and a new implementation underlying Events that will make them much more robust in general.

Regards,

Ben

[naughtyb1tz]

bump.

this is really annoying for mobile web developers as it blows up any meaningful use case for twitter follow. please fix web intents for mobile

[normandyann]

+1

[ericbojo]

any fix/ update to get around this?

[kawebah]

Any updates on this ?

[EmuseH5Dev]

any updates on this??

[byonepress]

It has been almost 2 years since this bug was reported. Please reply us, can we hope that you will fix it or not?

[benward]

Hi,

To clarify the state of events on mobile, I’m afraid there are a few different variables at work:

• The issue described earlier in this thread is fixed: Mobile and web logins have been unified for a while, so that issue is fixed.
• However, some mobile browsers don’t support PostMessage between windows (e.g. Google Chrome on iOS: https://code.google.com/p/chromium/issues/detail?id=136610), so we can’t send event messages yet.
• Finally, on Android the Twitter App may register itself against some Twitter HTTP URLs, and if the user chooses to open those URLs using the app instead of their web browser then we don’t have a channel to send event messages.

I’m sorry that the mobile landscape is so unreliable, it’s very frustrating for us too as we’d really love for events to be a more reliable application development tool than they currently are. We have ideas that will improve or work around some of the above issues, and there’s code written that will improve this, but it’s not ready yet, and it’s not our top development priority right now (we know that there are reliability issues in Internet Explorer to fix too.)

I really hope we’ll be able to offer a truly awesome events API in the future, but I’m afraid there’s no date yet. When we get it done we’ll be shouting about it.

Thanks for your patience,

Ben

[dtipson]

Ben, shot in the dark on this, but is there any way to detect that a page with intents has lost out to a native app? Guessing no, and everything else you’re saying about this problem makes sense. I may just try something as silly as the page visibility api here to guess when a user has both clicked a tweet link AND leaves the page within a certain amount of time.

Actually, now that I play around a bit more, the widgets.js may not even opening twitter intents as a “popup/new tab” on Android Chrome anymore, instead straight navigating to twitter.com in the existing tab, meaning that even on the same-browser flow, the original site/code is just gone (and the tweet complete state on twitter.com’s website doesn’t close, navigate back, or offer any way back).

iOS intent events (using widgets.js) work (they use window.open natively and close after tweeting, reporting the event), but IE9,10,11 don’t seem to fire the event at all with the current code (window.open, no event when the window closes). IE8 (unsupported) has that bug with the delete operator referenced in another ticket.

[benward]

We’ve played with the page visibility API a bit and found the results inconsistent so far (just early prototypes, mind you.) An implementation that worked in iOS7 didn’t work in iOS8… But because iOS pauses processes in the background we are able to do a crude timestamp comparison to detect when a page has been paused for a period of time, which has a similar implication. We’ve not had a chance to try that on Android though, where the multi-process model is different.

A proper API for this would be a godsend, but I’m also not sure how Apple or anyone would provide a useful enough API while also preventing ad networks scraping the apps a user has installed from an unauthenticated web page. The privacy balance makes it difficult. Maybe something whereby a Twitter domain could detect the Twitter app would work, but that’s all fiction.

We’ll hopefully find some time to work more on this in the near future, but there’s a lot else on so as I say, it’s not an imminent fix I’m afraid.

Ben

[dtipson]

Gotcha, really appreciate the background!

Right now, an attempt to open a new Android tab (Chrome/stock) via window.open pointing at https://twitter.com/intent/tweet (whether my code or widgets.js) is redirecting the calling page instead of creating a new tab (as it does on iOS).

This may be a side effect of how the meta name=“native-url” tag on the intents site is interpreted on Android: I’ve even tried having window.open open a local page that waits a few seconds and THEN redirects that new tab to https://twitter.com/intent/tweet, but the result is the same: this new tab opens, waits a few seconds, but then just closes and then the original site/tab redirects to twitter.com, never returning or linking back to the original site post tweet. (If the redirect is to a site like http://cnn.com though, the navigation works in the new tab and I’m left with two tabs as expected).

Best guess: not the fault of web intents at all, but rather just a quirk in how Android handles tabs/application intents.

[niall]