I'm building a webapp where users chan share links to other users.
Lets illustrate my problem with an example:
Alice is using the webapp.
Alice shares a link to Bob through messenger API.
Bob clicks the link that opens in the messenger browser.
Bob wants to share a link to Chris but it's not working since
messenger API can't open itself inside messenger browser !
I tried to fix this by adding href="_blank" but links keep opening theirselves inside the messenger browser.
Is there way to bypass messenger browser when user click on links (and use users' default browser instead) ? Without using Facebook settings.
Unfortunately, there is no such thing in the Messenger Platform Reference. Only the user can choose to bypass Messenger's browser in favor of his default mobile browser, through Messenger's settings.
href="_blank" shouldn't have any effect for two reasons:
It is written incorrectly. The correct syntax is target="_blank"
Even if it was written correctly, because it actually only tells the browser to open something in a new tab (or Window) not a different browser. Messenger's browser just ignores it since it doesn't support tabs.
Related
I'm driving traffic to a landing page with PPC on Twitter. Naturally, when they click on the ad in the Twitter app, it opens "embedded" in Twitter, which is usually WebView, but sometimes some vendor specific browser such as MIUI.
The issue I have is that 1/3rd+ of my traffic is running on Android 10 or earlier, and the Stripe code doesn't work in WebView (but it does work in Chrome on the same devices). So, what I'd like is to write a little bit of JavaScript that detects the OS version, and whether it's one of these system webview browsers instead of the "real" browser, and then insert something like:
"Unfortunately, this browser doesn't support payments. Please open this page in your phone's browser, or click this link".
Where the "click this link" link opens the same page in the "real" browser. Of course, I could just have the rest of the text without the link, but it seems like a better UX to me this way, if it's possible.
There's a similar question from 2015 that indicates it's possible in Java, but I'm not writing an app, this is just a web page, so I'm wondering if it's possible/how to do it in JavaScript.
We have a PWA linked to the Facebook advertisement. The problem is when clicking the advertisement from the FB app, it opens the PWA with FB's internal browser which doesn't support PWA features.
Question: Is there a way to open the PWA from FB post or any workaround for the problem? I have tried with dynamic links, but the link is also open in FB app internal browser.
Unfortunately, there is no way you can control how Facebook app behave. Instead, they allow user to choose whether to open link externally. User can go Settings -> Media & Contacts -> Links open externally to disabled the option.
Reference: https://countdownwebdesign.com/quick-tip-open-facebook-links-in-chrome/
I'm creating this landing page that's supposed to be triggered by a captive portal.
on my landing page, there's a button to trigger open a <video> element which is then used to scan the QR code.
By default, upon accessing the webcam or device's camera the browser would ask the user's permission first. So basically everything is working fine and all on the browser.
Upon lodging it as a landing page triggered by the captive portal, some inconsistencies arose.
On most Android phones my colleagues have, they simply deny the permission by default.
On some android devices, the popup message asking for permission is shown, and working as expected just like the browser version.
On IOS devices, the popup simply gets blocked (not denied, but ignored)
I know it is ignored on IOS because the error message is not even showing, as if no action is given to the popup by the captive portal.
I've read several forums on captive portals, all led me to believe that captive portals by nature are simply a lighter version of a built-in browser that simply doesn't have the capacity to run window.alert() and window.confirm() nor the ability to keep cookies.
My "research" also led me to believe that captive portals have different sets of behavior unique to the OS, not the browser installed on that OS per se.
1 blog I read today, specifically the comment section, mentioned that from IOS 11.2 on, captive portals should already be able to run window.alert() and window.confirm(). However, upon testing it, this simply isn't the case.
So my question is, is there any way to work around this limitation, by still allowing users to decide whether to allow or deny camera access?
My "research" shows that it is impossible to redirect a captive portal to open on a browser programmatically and only a handful of phones have a captive portal that comes with the "open in browser" option.
Does anyone know any way to, say, intercept the permission popup in action and display it as just a normal HTML element then pass back the user response programmatically?
Thanks in advance! :)
Interfering with system UI flows is not possible. Running code tied to system UI must me tightly controlled to not allow user extorting schemes, like 'Do this with your phone to gain internet access'. Captive Portals from an OS vendor perspective are only about consenting or rejecting the terms of internet use through a provider.
You must change to a two-tiered approach, serving a captive portal and a landing page separately:
Let users check the captive portal
Serve your landing page when they use the browser.
To facilitate and prepare users for the 2nd tier, include a link to your landing page in your captive portal, saying something like 'Start using internet here'. Also have a look at the latest changes in Android and Apple's OSs with regard to Captive Portal API and Captive-Portal Identification in DHCP / RA. (via)
Think of the constrained captive portal as device side aspect, the rich UI landing page as a provider side aspect of accessing internet that can't be united for security reasons.
I'd like to have a single 'Get App' link that auto-detects the user's device type and browser and directs to the appropriate location (iTunes, Google Play, or website sign-up). I am currently using Onelink.to, but it has the following limitations:
if you're on iOS using a non-Safari browser (like Chrome) you end up looking at a bunch of raw JSON because it doesn't know to launch the App Store app. In this case, I'd prefer to direct to the iTunes website or better yet, deep link into the App Store app.
if using the link on your own site and a user is on a device that redirects to a different page of your own website, it complicates setting up event-based goals in Google Analytics
Are there any good JavaScript solutions that handle the App Store redirect while excluding this action on browsers that don't support the iTunes headers?
Thanks!
You can use javascript navigator.userAgent and parse it to detect the device. Then just generate the link according to it.
Here is an example for ios detection:
Detect if device is iOS
I have been implementing PayPal Digital Goods Express Checkout in my (HTML5) web app to enable the 'in-app' purchase of extra app content. In my desktop browsers (Chrome, Safari, Firefox) the digital goods flow works without problems. In that flow popup windows are opened at some points, for instance when the user clicks the login button or the button to pay with his creditcard (i.e. without having a paypal account). The popups are no problem for the desktop browsers. However, in Mobile Safari on my iPad 2 popup windows are always opened as (new) tabs, even if a property string containing width, height, etc. is passed to a JavaScript window.open() command. This makes it impossible to implement PayPal Digital Goods Express Checkout and have a good user experience in both desktop browsers and Mobile Safari. When the web app is run full-screen on the iPad (using an icon on the home screen) opening the popups becomes even more problematic (or impossible).
In trying to solve my problem I came up with the following options, none of which has yet led to satisfying results:
Customize the payment flow. Of course this is possible to some point, but after having redirected the user to the 'incontext' Express Checkout page that forces the user to login to PayPal, customization is out of my hands (as far as I know). For instance, I cannot customize the login process itself and make it work in an iframe (instead of a popup window) instead. It would be cool if there were some advanced API commands that I could use server-side to make the user login to PayPal myself, using my own (iframed) login form, but this seems too far-fetched.
Make popup windows work like expected in Mobile Safari, preferably also when a web app is run full-screen. I don't think it strange that Mobile Safari opens new windows as tabs (there are other browsers that do this). I do think it is strange that popup windows that are opened from JavaScript, using window.open and a property string that defines the window's position and dimensions, are opened as tabs. Does anyone know how to make Mobile Safari open such popup windows normally without requiring the users to change some browser setting?
To demonstrate my problem (and show that I am not the only one facing it, though this site's owner probably doesn't know it ;-), go to digitalmagazine.autosport.com with your iPad and click the 'Pay with PayPal' button at the top-left of the page. Click the login button in the PayPal iframe. The site disappears and the login page (that is supposed to be opened in a popup window for an 'in-app' experience) opens full page.
I have also looked at the client side (JavaScript) techniques that are used by similar in-app payment systems, but those (understandably) also use popup windows. Therefore I would prefer the second solution that I have described above. That one will also involve much less work.
While PayPal supports the mobile platform, you will need to make some changes to fully implement it for iOS and other mobile operating systems. You will find the PayPal Mobile overview here: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_ECOnMobileDevices
The process starts with changing the redirect command in Express Checkout flow to _expresscheckout-mobile, and then steps through a list of additional requirements for full implementation. Read the documentation carefully, as it can be a bit picky when it comes to supported NVP fields.