This questions is related to this other one I posted a few days ago:
Instagram oAuth Authentication postMessage issue only with Mobile Browsers
Pretty much the issue I have is that when logging in my app with Instagram Chrome will behave inconsistently (on Android) and cause me some problems.
As I say in that other thread, IG authentication will reply with the required token and data to authenticate the user in my app.
It will do this by replying with a script that sends that data back to the original window, using window.opener.postMessage().
When I run my app on Chrome in Incognito mode, window.opener.postMessage will work without any issue since only one tab is opened and the reference to the opener isn't lost.
However, when I run this on the same browser but in regular mode (like probably 90% of people will) the behaviour is different.
Chrome will open a tab, close it and open a new one to input auth data. However, window.opener here won't work because the opener reference has been lost (is now null).
How come the same browser, on the same device will have such a different behaviour between two modes?
Does anybody know why this happens and how to prevent this from happening?
Related
I have a pwa1 which will open in in-app browser of pwa2. I have install button for pwa1. But in in-app browser beforeinstallpromt is not getting fired. Any workaround for this?
Open in Chrome this link will open in chrome app from any other browser in Android except in-app browser of PWA. Any way to make it work for in-app browser?
Web share api shows lots of app when clicking share button except chrome app. Any way to add chrome app in sharing suggestions?
No, this only works in top-level browsing contexts according to the spec, but not in nested contexts.
Not that I know of, probably due to a similar limitation as above.
Chrome is not a share target, but you can copy the URL and open the URL on the clipboard with Chrome.
I have a web app that uses a cookie as an access token (to let users stay logged in after refreshing/closing the site/app). It works perfectly on desktop but when I try to use it on my Android phone (installing it via Chrome), for some reason it says that I'm not logged in which means it wasn't able to load the access token.
Why is this happening? Is there a difference between how cookies are handled in the browser and when starting a PWA as a standalone?
Also two little side questions, 1, is there a way to debug a PWA that's added to the homescreen (using some sort of remote debugger) and 2, would it be a security risk to use localStorage for storing the access token instead of a cookie? I realize neither is particularly safe but I read that cookies are slightly better for this sort of thing. localStorage works just fine when starting as a standalone
I'm building a Chrome plugin that tracks users' browsing history, but I'd like to ignore any mobile browsing, keeping only the logs that occurred on a signed-in desktop browser.
I'm also confused about whether the extension code itself runs on signed-in mobile browsers – my event script (using chrome.alarms) occasionally sends browsing logs to a server, and I can see logs being sent even when my laptop is closed, but they usually correspond to when I'm using Chrome on my iPhone.
I can't find any information on either of these issues Chrome's developer portal.
I'm also confused about whether the extension code itself runs on signed-in mobile browsers
Well, for one, mobile Chrome does not support extensions; as such, there is no such risks.
However, an extension published on Chrome Web Store will, by default, replicate itself upon installation to other Chrome profiles that are signed into the same account as part of Chrome Sync. The only way to prevent it is to disable extension sync for the profile, which also makes chrome.storage.sync to stop replicating.
So your "unexpected" logs may come from another desktop Chrome that's signed into the same account - assuming the extension is actually published in CWS.
is there a client based javascript way to detect Eddystone-URL beacons directly from the Chrome browser in iOS?
I know Chrome has the widget for the today view wich works fine, but I need to detect new Eddystones without pulling down the notifcations window.
Say a user clicks on a link provided by the widget, gets redirected to the Chrome app, does stuff, walks around and gets in range from another beacon.
Right now he would have to pull down the tab again to receive the new URI. But I need some sort of notification from within the Browser.
I hope you get the idea.
Thanks in advance!
Cheers
p.
Unfortunately, this is not possible. Understand that Chrome for iOS is just a thin app around the standard native iOS UIWebView, so there is nothing you can do in JavaScript that you cannot do in Safari. And Apple does not implemented any JavaScript bindings to the CoreBluetooth APIs that would be needed to detect Eddystone-URL beacons. The bottleneck is more of an iOS restriction than a Chrome browser one.
Note that this is not true for the Chrome browser on other platforms, notably ChromeOS, which does provide such JavaScript APIs.
I have an issue where I'm asking my app to open a browser looking at my Server.
From that server page, The user can perform some stuff on an existing site, then redirects the user to a URL that the App catches and the App continues as normal.
The lifecycle looks like this:
App -> Web Site -> App
However, after the life cycle of the app and the app is closed, the webpage is still open in the browser (on the page where the redirect to the app occurred).
It's apparently difficult via javascript to close a tab which wasn't opened by javascript? (In my case, the tab was opened by the app, not by a different tab). Is there any way to get around this?
(I'm aware I could use a WebView, but WebViews are buggy, manufacturer specific, security holes that I want to avoid)
No, sorry. There is no standard Intent structure for this. While it is possible that some browsers offer something, I am not aware of any that do.
Bear in mind that there is no requirement that your ACTION_VIEW Intent open up a browser tab, as the user's chosen browser may not offer any sort of tab UI metaphor. check this reference old question