Our site uses PWA so that the visitor can choose to Add to Home Screen (A2HS). However, from Google Analytics data, the Dismiss rate is too high compared to Acceptance rate.
We plan to make the UX more intuitive and clearer to improve the acceptance rate. However, we also want to revive those visitors already dismissed the A2HS dialog.
How to do so? To the extend of my knowledge, we only can add beforeinstallprompt listener but there is no openinstallprompt method.
For security reasons, as others have written as well, browsers don't allow you to manually trigger the install event.
However, there is a way you can test it yourself. Go to chrome://flags and enable "Bypass user engagement checks"
This will kick off the prompt so you can test.
Cheers
No, You can't trigger the install banner and its driven by the browsers. If your site meets all PWA criteria and if the user is visiting frequent enough(how frequent enough is not explicitly stated by browser vendors), browsers will show the prompt again. We can't trigger the same with our code. Refer this answer on why it behaves that way and whats the alternate solution.
Anand's answer is correct for now. But starting Chrome 68, Chrome will not automatically show the A2HS prompt. You will need to explicitly tell Chrome to trigger the prompt.
According to Google's documentation, here is the snippet of code to handle the prompt;
Listen for the beforeinstallprompt
let deferredPrompt;
window.addEventListener('beforeinstallprompt', (e) => {
// Prevent Chrome 67 and earlier from automatically showing the prompt
e.preventDefault();
// Stash the event so it can be triggered later.
deferredPrompt = e;
});
Insert the following code in a listener that will trigger the prompt
// Show the prompt
deferredPrompt.prompt();
// Wait for the user to respond to the prompt
deferredPrompt.userChoice
.then((choiceResult) => {
if (choiceResult.outcome === 'accepted') {
console.log('User accepted the A2HS prompt');
} else {
console.log('User dismissed the A2HS prompt');
}
deferredPrompt = null;
});
Refer this link for further information.
In Dev mode,
Try this in devtools(tried in chrome) console to trigger the event:
event = new Event('beforeinstallprompt')
window.dispatchEvent(event)
Caution: We won't be able to open the in-browser modal by calling prompt on the event.
Related
I'm running Chrome 56.0.x (corporate mandate), along with Polymer 2. My sample component isn't doing anything fancy; just raising a CustomEvent after making a simple AJAX call. I'm setting "bubbles":true and "composed":true, and I can validate that the event is dispatched and that my host is listening for the event properly.
sample-component.html
raiseDataRetrievedEvent() {
this.dispatchEvent(
new CustomEvent('sample-component-data-retrieved', {
bubbles: true,
composed: true,
detail: { data: "loading complete" }
}));
}
However, the events never make it out of the Shadow DOM to my host page listeners.
index.html
// Listen to Custom event from Sample Component
document.querySelector('sample-component').addEventListener('sample-component-data-retrieved', function (e) {
alert(e.detail);
console.log(e.detail);
});
Interestingly enough, when I have a user initiated event (e.g. click) trigger this CustomEvent, it happily makes its way through the Shadow DOM to my listener. It's just the events that are programmatically created that are getting stuck.
UPDATE 1
This issue only seems to manifest itself when I'm serving my site locally (e.g. http://localhost, http://127.0.0.1, http://COMPUTERNAME). When I publish the site to another host, all the events seem to propagate as expected. Feels to me more like a Chrome issue at this point...
UPDATE 2
I put my code out on github here: https://github.com/davidfilkins/polymer-test.
I did some more testing and the results keep getting weirder... when I'm developing / testing in Chrome, I almost always have Dev Tools open. I noticed strangely enough that when my tools are open, that the event isn't captured by the host page (index.html)... but this seems to only happen locally. When I close tools and load the page locally, the events bubble properly... But this is only for the dispatched events that aren’t tied to an explicit user action; those all seem to work regardless of the tools being open or not.
When I access the simple Azure app that I created - http://samplepolymertwo.azurewebsites.net/index.html - all events are bubbled / captured regardless of whether the tools are open.
No clue if this is fixed in more current versions of Chrome or not.
The culprit was all timing...
In Chrome, with Dev Tools open, running on localhost, the event was dispatched from the component before the event listener was wired up on the host page.
Event Timing
I suppose the ideal scenario would be for the web component to wait until the event listener on the host had been wired up before broadcasting the event.
I have a UI test which involves the dismissal of a system-generated UIAlertController. This alert asks the user for the permission to access the device's calendar. The objective of the test is the behaviour after a tap on the OK button:
1 let app = XCUIApplication()
...
// this code was basically generated by the recording feature of XCode 7
2 app.alerts.elementBoundByIndex(0).collectionViews.buttons["OK"].tap()
Now, instead of clicking the OK button, line 2 makes the simulator tap onto the first button which happens to be the Cancel button...
Additionally, I found out that the testing framework does not accurately recognize the appearing alert. So if I check the current count of alerts I always get 0:
// ...tap...
let count = app.alerts.count // == 0
This also happens if I use an NSPredicate for the condition and wait for several seconds.
Is it possible that UI tests do not work reliably with system-generated alerts? I am using XCode 7.0.1.
Xcode 7.1 has finally fixed the issue with system alerts. There are, however, two small gotchas.
First, you need to set up a "UI Interuption Handler" before presenting the alert. This is our way of telling the framework how to handle an alert when it appears.
Second, after presenting the alert you must interact with the interface. Simply tapping the app works just fine, but is required.
addUIInterruptionMonitorWithDescription("Location Dialog") { (alert) -> Bool in
alert.buttons["Allow"].tap()
return true
}
app.buttons["Request Location"].tap()
app.tap() // need to interact with the app for the handler to fire
The "Location Dialog" is just a string to help the developer identify which handler was accessed, it is not specific to the type of alert. I believe that returning true from the handler marks it as "complete", which means it won't be called again.
I managed to dismiss access prompt for contacts like this:
let alert = app.alerts["\u{201c}******\u{201d} Would Like to Access Your Contacts"].collectionViews.buttons["OK"]
if alert.exists
{
alert.tap()
}
Replace asterisks with your app's name. It might work the same for calendar.
This is what I ended up using to get the prompt to appear and then allow access to Contacts:
func allowAccessToContacts(textFieldsName: String)
{
let app = XCUIApplication()
let textField = app.textFields[textFieldsName]
textField.tap()
textField.typeText("aaa")
let alert = app.alerts["\u{201c}******\u{201d} Would Like to Access Your Contacts"].collectionViews.buttons["OK"]
if alert.exists
{
alert.tap()
}
textField.typeText("\u{8}\u{8}\u{8}")
}
I've been reading through the docs for Chrome's implementation of the Web Push API here, and I noticed the API says "you promise to show a notification whenever you receive a push" and under limitations it's stated "you have to show a notification when you receive a push message".
After implementing the example on my localhost, I used cURL to send a push notification successfully. I was curious, so I commented out the lines that actually call the showNotification function, and put in a console.log instead and found that I could, in fact, send, receive, and totally ignore a push notification. I even tried using an if-statement to control whether or not to show them based on global boolean that I controlled from my main page, and that worked. So I was wondering if anyone knew what they meant by saying you need to show a notification, and that silent push notifications weren't available?
This wasn't just for the heck of it, I legitimately may need to control whether or not to show these notifications in my web app, so it would be great if this were actually possible. Code below in case you're curious.
self.addEventListener('push', function(event) {
var title = 'New Message';
var body = 'You have received a new message!';
var icon = '/img/favicon.png';
var tag = 'well-notification';
console.log("DID RECEIVE NOTIFICATION")
if(settingsShowNotification) {
event.waitUntil(
self.registration.showNotification(title, {
body: body,
icon: icon,
tag: tag
})
);
}
});
EDIT: On Chrome 47, if it's relevant.
UPDATE: After further experimenting, I found the obvious issue that I can't update the original global variable once the user navigates away and then re-navigates to the same page. However, I was able to circumvent this using a variable on the serviceworker itself and sending a message to the service worker using the API described here to toggle the showNotifications boolean.
You do have to show a notification, and if you don't show a notification you get a forced notification from the browser saying "This site has been updated in the background". But the requirements that show the scary message have been relaxed slightly:
As of Jan. '16, it seems like up to the last 10 notifications are checked for whether each showed a notification or not. If one notification in the last ten notifications did not show a notification, that's considered an accident and the browser won't show the scary "This site has been updated in the background". You have to miss two notifications in the last ten for the scary message to appear.
Note: If the URL in the address bar of the active browser tab matches the origin of your page, and the browser is not minimized, you are not required to show a notification. This is probably why your tests succeeded, if you were on the page itself while running your tests.
Chromium bug that tracks the implementation: https://code.google.com/p/chromium/issues/detail?id=437277
Relevant lines of source code: https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/push_messaging/push_messaging_notification_manager.cc&l=249
I have a Chrome kiosk app that basically just uses webview to allow someone to browse through a catalog.
I found the chrome.idle API, and believe I understand how to set idle time and query if the device is idle, but can I have it restart the application when the state changes to idle or at least navigate back to a set URL?
The end goal is to have the catalog reset itself for the next user after being left idle for a set period of time.
https://developer.chrome.com/apps/idle
Well, the documentation is pretty clear..
First, you need to declare in the manifest that you want to use this API, as it needs a permission.
"permissions" : ["idle"],
You could go with a poll-based approach as you suggested, but why? There's an event provided. So, we go on to use that.
You need to inform Chrome how long an interval without user input you consider an idle state.
chrome.idle.setDetectionInterval(120); // 120 seconds
Lastly, you need to react to a change to an idle state.
chrome.idle.onStateChanged.addListener(function(newState) {
if(newState == "idle") {
// Reset the state as you wish
}
});
Is there event that will notify a sender app when the use selects "stop cast" from within the chrome extension?
I've a chrome sender app get's in a limbo state if the user chooses to stop the cast from the extension instead of the app cast button.
EDIT:
This is some relevant code:
CastPlayer.prototype.onMediaDiscovered = function (how, mediaSession) {
this.currentMediaSession = mediaSession;
// ...
this.currentMediaSession.addUpdateListener(this.onMediaStatusUpdate.bind(this));
// ...
};
CastPlayer.prototype.onMediaStatusUpdate = function (e) {
console.log(e);
};
Have you tried Session.addUpdateListener(listener) ? I think the listener will be notified when the session is no longer alive.
It seems Google developers are pretty aware of that! :D
They've just update their senders sample code with a commit that is exactly what seems you're looking for: Added session update listener to handle disconnect by clicking cast extension
There's also another commit with the same text in another sample but with less code, here you have: https://github.com/googlecast/CastHelloVideo-chrome/commit/776559c9aaf16d7d82c62ee4dea611b6177ac217