Trying to write a chrome extension using the chrome.history api. I'm seeing the history reported by chrome.history doesn't contain links visited on other devices (although those links do appear in the chrome://history page on the same device).
Is there an alternative to chrome.history I could use? Is there something else than an extension I could build that could access the full cross device history?
Or is there a reason for the discrepancy between chrome://history and chrome.history?
My end goal would be to highlight links that have been visited cross devices on current pages.
Thanks for any help!
You can check out this answer on Super User which
Reset Sync by going to the Google Dashboard.
Log out of Chrome on all your devices (PC, Mac, smartphone, etc)
Quit Chrome (kill Chrome process if necessary)
Run Chrome again and you should be asked to sign in to your account.
Once all accounts are signed in, the history should sync across all devices
This will re-sync all your devices.
By the way, extensions usually are synced to all devices if users enable the feature, and this means that your app will still show the visited links since it will have access to the device it's installed on's history.
As for the synced data, not event the Chrome browser itself can highlight the data as visited. Google.com usually highlights visited sites, but I just checked my history and the sites I visited on other sites aren't showing.
To solve your issue, you can have users create Premium accounts that gives them access to cross browser link marking. This of course has to be implemented by you.
Related
I know there is an offline mode in google chrome but my question is there a way for a website to force chrome to cache the entire website for offline loading without user interaction (besides the user initially visiting of course)
Example:
User visits website X,
X requests chrome to cache specific version of the site for offline use
User brings up the website at a later date without internet (without deleting cache/history of course) and can now view the site html/Javascript.
If this behavior is not currently available in chrome what would be the most seamless way to accomplish this behavior with the end user being random devices using chrome, simply providing them instructions to enable offline mode? Or is there a way to force this prompt?
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.
So the simple idea is that we have a RADIUS server setup to allow users to authenticate with our Ruckus controller via user credentials. On authentication the user should be redirected to a page that allows them to manage MAC authenticated devices.
On everything we have tested so far, including "older" Android devices this seems to be no issue and things run as they should. However with Lollipop (5.0+) versions of Android the captive portal has changed quite a bit, and part of that change is to automatically close the captive portal that launches when you join the network. Because we want them to be redirected to a MAC device management page after authentication so they can add the device they currently logged in with and avoid having to log in again, this is bad.
What I have tried:
Detecting if the browser is being launched in a mobile device and popping an alert in onbeforeunload that attempts to keep the browser open.
Opening a new browser window, pointing to the redirection URL, when successful authentication is detected (essentially managing the redirect ourselves).
Performing Option 2, and then Option 1 on the redirected URL
What won't work:
Asking users to disable the captive portal option on their device. Not trying to point general users to advanced controls.
Creating an open network to access the MAC manager, it must be behind some authentication.
Solution For Now:
We are unhappy with this solution, but for now we are simply asking users to authenticate with the network and then open their browser and go to the basic login portal page (non-network authentication) that users use to manually add devices they can't connect with (like printers, gaming devices, etc.). Though this works, it is a pain for users to have to login, open a browser, manually enter a url, and login again.
This isn't a problem that people haven't run into, see here, I just haven't been able to find a solution from anyone that has run into the problem. Certainly there is some way of utilizing javascript or something to keep the browser open in this situation. If not, anyone have any better ideas for managing things?
We have managed to keep the UAM Browser / captive portal browser open on lollipop by adding firewall rules blocking :
clients3.google.com
clients1.google.com ,
android.clients.google.com
connectivitycheck.android.com
connectivitycheck.gstatic.com
Thus after the user is authenticated the UAM / Captive Browser stays open.
You can keep UAM open as long as you need, you can close it by invoking a reverse proxied 204 redirect to google's connectivity page.
This appears to be new Captive Portal behavior in Android devices since the release of Lollipop (5.0).
We have not yet discovered a workaround. If there is an explicit way to disable the auto-dismissal it is probably only documented in the Android codebase available here (I've been looking, but haven't found anything definitive yet):
https://android.googlesource.com/platform/frameworks/base
FYI, we've also noticed Android uses CloudFront CDN for its captive network detection. Our captive portal solution originally used CloudFront for assets, so we had to whitelist CloudFront subnets in pre-auth ACLs. Whitelisting CloudFront subsequently caused captive network detection to fail on recent Android devices. We had to abandon CloudFront CDN to restore captive portal functionality for Android devices.
Why don't you just hold captive portal opened after authentication? You can always allow access to every site except captive checking sites.
Tested and working both Android and iOS in all versions.
If you need to access cookies/shared storage from default browser (not captive ios/android sandboxed browser), you gotta hop out it before authentication.
Google came up with a new feature called Google Web Light. This optimizes websites that are not mobile friendly and are heavy for users with slow connections. Sometimes even YouTube gets optimized.
They URL is like this "http://googleweblight.com/?lite_url= website url".
So, this causes some issues to websites. Mostly JavaScript issues. Take a look at these jQuery UI elements. Nothing seems to work.
Sure there is a link to view the proper website but users won't bother clicking and would leave thinking the website is broken.
How would you go around this. Is there anyway to detect if the users browser is showing the optimized website?
Here is an example of what it looks like:
This explains how to opt out of WebLite:
If you do not want your pages to be transcoded, set the HTTP header "Cache-Control: no-transform" in your page response. If Googlebot sees this header, your page will not be transcoded.
To detect WebLite instead use $(document).ready() in a script to detect if one of those new WebLite elements exists in the loaded DOM:
if (document.getElementById('lite-menu') != "null") {
alert("WebLite is being used") ;
}
If you have a fully responsite site then WebLite will only be used for slow connections
To those of you that land on this page because you keep getting redirects using Google Web Light:
Download firefox through Raspbian Repository (or your default linux distro repository) and then seek out a browser addon to change "user agent" to desktop (just search addons for "User Agent" and you'll find something). Once done, Google will no longer terrorize you with an service they think helps you so they force it upon you.
(This may apply to others not using Raspbian such as any mobile device or small screen computer).
I want to create a Google Sites script that can detect whether my visitors are using Android or iOS and then redirect them to AppStore or Google Play accordingly.
This will allow me to advertise only one QR code for all devices.
Is there a way to easily set it up and host it on Google Sites?
Well the script needs to inspect the HTTP_USER_AGENT header, and do something like this:
Common link to open iOS, Android and BlackBerry app
Bear in mind that not everyone on an Android-based device has the Google Play store (e.g. Kindle Fire -> Amazon Appstore); unfortunately getting the user to an appropriate app store on Android is tricky because there are many options.