My team created a plugin, one of our customers is having issues with our plugin only in the mobile apps for their test users.
There are 2 redirect URIs and the mobile app is loading the second URI (our application) inside the plugin card. This is only happening intermittently and seems to be solved by a hard refresh of the application. Due this issue only occurring in a mobile environment and by test users for only one of our clients, I believe something is happening in the mobile app itself or something with the test users configurations inside the Banno ecosystem is causing problems (this is not the first client who has had problems originating from only enabling my plugin for a subset of users).
There is another intermittent issue where the user is prompted to login when clicking the button to launch our application from the plugin card, even though they are behind the login inside the app. Again, this is only occurring for this client, in the mobile experiences, and with their test users.
I am at a loss as to how to troubleshoot this in order to get to the root of the issues.
Please advise.
We have tested this on both mobile apps and in the browser. The issue seems to be originating in the mobile apps.
Related
I've written a simple web app to factory-reset bluetooth devices that were accidentally turned on during shipping. The app scans for a class of bluetooth devices (those made by the company I work for), renders a list of devices found, and, when I click a button next to a device in the list, sends a reset message to the device.
This is a very manual process and I'd like to automate it. The problem is the Chrome dialog that asks for permissions to pair with a device. I am trying automate the app with Puppeteer, but I can't find a way to either (a) programmatically grant permissions to pair with a device or (b) to select the device in the dialog and click the "pair" button via Puppeteer. Anyone know if what I'm trying to do is possible, or if there's a better way to achieve the goal? Thanks!
This is not possible in Chrome. (I work on chrome.) The automation that does exist for Chrome's testing is layered such that actual Bluetooth connections aren't made.
Eventually we would like to enable this workflow via Enterprise configuration controls. But that is not started yet and there is no date commitment.
One alternative is to use node.js, though you lose the easy interface. You might build the reset backend in a node server and have it serve a web page interface.
I'm resurrecting an old project of mine as a way to learn some new stuff.
I'm doing this code lab from IO Add Your Web App to a User's Home Screen.
Is there any way, other than connecting a phone and waiting a lot, to test if users will be shown the prompt below?
I've tested it with Lighthouse and all tests come back green, but I've never seen the prompt. It feels very random at the moment.
The answer to This question puts the stuggle into perspective:
The user has visited your site twice over two separate days during the course of two weeks
Does that mean I need to wait 2 days between changes to see if it worked?
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Increasing Engagement with Web App Install Banners
anshulix has correctly answered the question, but I thought I'd put in a more verbose answer.
To remove the waiting and other requirements for the save to homescreen prompt, then you need to enable a flag.
Enable chrome://flags/#bypass-app-banner-engagement-checks and you will see the banner as long as you have a manifest (configured correctly) and are on HTTPS and have a service worker.
Which comes from Increasing Engagement with Web App Install Banners
It's important to remember that you are setting this flag on the mobile browser, not on your desktop browser. For some reason this didn't occur to be for a while!
You also need to restart mobile Chrome for the flag to take effect. If you've got your tabs mixed in with your other apps, this can be tricky because you need to hunt down all the tabs and close them. (Or find a better way to close Chrome.)
I found it much easier to do this debugging in Chrome Dev, rather than regular chrome because a) I know it's got the latest fixes in it, and b) because I only have 1 tab open, so it's easy to restart the browser.
If you are doing remote inspection, there is an issue about the messages that come up in the console. In Chrome 50 you get:
App banner not shown: could not determine the best icon to use
This doesn't seem to be true; in more recent builds—e.g. mobile Chrome 52—save to desktop works just fine. It's a disconcerting but useless error.
As a bonus helpful thing, realfavicongenerator does an excellent job of generating all the icons and the manifest file that you need.
I'm developing a line of business app for Windows 8.1, that is, I am not deploying through the Windows Store and will be able to control all of the features of both the OS and hardware this app is being deployed on.
Because this app is working as the UI in a real-time situation I would prefer if I could ignore the life-cycle events and not have the app suspend or terminate at the whim of Windows 8. Does anyone know of a way to do this?
I have seen some older answers, such as this one and this other one indicating otherwise, but I haven't yet found anything more recently and specifically dealing with the case of a line of business app. I have found the Embedded Lockdown Manager which would prevent the app losing focus and addresses some of the needs I have, but I still would like a way to simple disable Lifecycle events.
Have you tried Assigned Access Mode? Basically use PC Settings -> Accounts to lock an account to a single app. You have to reboot the device and log-in again in order to run anything else.
I am about to start, working on a offline web application using HTML5, indexed db.
I have been reading a lot about it. But I got little confused thinking if the user deletes the cache of the browser, my app cache would also got deleted. And then there would be no way to use the application offline, until we got connected to internet, and browser creates a fresh cache.
Is this assumption true..or Is there a way to protect the app cache from getting deleted accidentally.
No. There isn't.
This is a normal behaviour which is similar to mobile apps. If users've removed their native apps, they need to redownload them whenever they want to reuse those apps. Appcache is not a silver bullet for the case.
I'm trying to develop a Google Chrome Extension app VoIP softphone. I will be using the Inline Installation feature (https://developer.chrome.com/webstore/inline_installation) and will be publishing on the Chrome Developer Dashboard (https://chrome.google.com/webstore/developer/dashboard)
My problem is due to the nature of the softphone that has to be always connected, every time I need to publish an updated version of the softphone users will be disconnected, and this will be a big hit on user experience.
Anyone ran into the same issues in publishing a softphone extension app in Google Chrome?
An update may be downloaded at any time, but an extension is only reloaded when the background page goes inactive.
I guess that you're using Web sockets for signaling. Since the connection need to be available at all times, you are probably using a persistent background page. This is enough to prevent a sudden unload. If you use event pages, then you need to jump through some hoops to get the page to stay alive even if the Web Socket is not busy all the time (crbug.com/204573), but also in this case, the extension will not suddenly be reloaded.
If you do want to reload an extension after an update, add a chrome.runtime.onUpdateAvailable listener and call chrome.runtime.reload when it is convenient (e.g. when the user has unregistered their soft phone, and/or when the user is idle, etc.).
The dashboard provides the ability to ramp up your updates. So only a small percentage of users will be affected at any time under your control.
In addition to the a slow ramp you can do it during off hours to minimize user experience.
This won't solve for disconnections during the update but could minimize the impact.