Hi Anajjar, On Jul 7, 2011, at 6:28 AM, anaj...@ibs.com.jo wrote:
> the login page will appear and you can see the cancel button,click on cancel > button,now it should return the user back to that link and as you can see the > link has a querystring original_referer with the original url so the cancel > button SHOULD return back to that url,but you will notice that it doesn't > return the user back to that page and instead it redirects to twitter homepage Ah, you've found a bug. Thanks! I'll fix that. The cancel button there should behave the same way as cancel buttons elsewhere (e.g. in the after-Tweet screen) and redirect to the original referrer. On Jul 2, 2011, anaj...@ibs.com.jo wrote: > In Safari I don't have any issues,but I do have issues with tweet > button within the container,once the login window of twitter appears > and user clicks on cancel it doesn't return the user back to my > page,instead it redirects the user to twitter homepage,Is there any > solution for this? For what it's worth, this is the full cascade of behaviours that Cancel buttons have within Web Intents: 1. If the intent is a pop-up window (e.g. if `window.opener` is available) then clicking a cancel button will close the window. On desktop, this closes the window as you'd expect. On mobile platforms such as the iPhone, this closes the page and flips the user back to the page that invoked the Intent. 2. If `window.opener` isn't available, then the page is assumed to have been navigated to conventionally. In this case, the destination of cancel links is (or should be) set with the following priority: 2a. To the original_referrer, if available and valid. 2b. If original_referrer is not set, or if the original_referrer is an invalid URL, or that URL falls foul of our known-malware-URL filter, then the cancel buttons will simply point to twitter.com. Finally, note that if you “pop up” an intent within a WebView in a native app, that does not set `window.opener`, so the page will believe it's been invoked directly in a browser (because it has.) If you want to handle the close event, you'll need to watch the source URLs. If it's possible to create a WebView on your platform of choice, and set a default window.opener *and* override window.close() with a call to native ‘close the WebView’ code, then you may be able invoke the Intent in a WebView and have all the autoclose behaviour from the web work. I've never tried this though. Ben -- @benward Twitter, Web Intents developer -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
