I am trying to create a notification in Chrome.
I have write this simple code but there is notification shown in CHrome whereas checkPermission() return well 0.
I do the same thing than this website (example), which works fine in my Chrome browser.
if (window.webkitNotifications.checkPermission() == 0) {
window.webkitNotifications.createNotification("icon.png", "title", "text").show();
} else {
window.webkitNotifications.requestPermission();
}
Where is the problem ?
[EDIT : Problem fixed]
In fact, i allows to show notification from all website in Chrome settings, and now, it works fine !
Request permission only work on a user gesture (see below question, and quote from the docs).
In short you need to register a click event or something similar then request permission.
document.querySelector('#show_button').addEventListener('click', function() {
if (window.webkitNotifications.checkPermission() == 0) { // 0 is PERMISSION_ALLOWED
var notification = window.webkitNotifications.createNotification(
'icon.png', 'Notification Title', 'Notification content...');
notification.show();
} else {
window.webkitNotifications.requestPermission();
}
}, false);
Here's a jsfiddle
Webkit notifications requestPermission function doesn't work
requestPermission Requests that the user agent ask the user for
permission to show notifications from scripts. This method should only
be called while handling a user gesture; in other circumstances it
will have no effect. This method is asynchronous. The function
provided in callback will be invoked when the user has responded to
the permission request. If the current permission level is
PERMISSION_DENIED, the user agent may take no action in response to
requestPermission.
Related
In iOS 13 Apple has introduced the API DeviceOrientationEvent.requestPermission. It must be triggered on user action (click, tap or equivalent).
My problem here is that the result seems to be cached, so in case the user denies permission I can't ask access again (the promise is automatically fulfilled with the cached value).
Is there any way to force the device to forgot the cached value and ask again for the user permission to access orientation data (I mean it should display again the popup window where the user can allow or deny access)?
This is the relevant code:
if (DeviceOrientationEvent && typeof(DeviceOrientationEvent.requestPermission) === "function") {
const permissionState = await DeviceOrientationEvent.requestPermission();
if (permissionState === "granted") {
// Permission granted
} else {
// Permission denied
}
}
Try simply to quit Safari and launch it back.
The prompt will come back.
I see the same behavior on iOS 13 Safari. You need to remove the website data for the particular site that needs permission. Go to Settings > Safari > Advanced > Website data, lookup the site and remove all the data.
Then the prompt should show up again when you ask for permission.
Are you sure it's a caching issue? I cannot get incognito Safari in iOS 13 to respond with a "granted" permission. I'm getting a "denied" response immediately - no prompt.
I'm using the following code to test the result, but it's always "denied" immediately without a prompt event showing. (https://codepen.io/ejarnutowski/pen/WNePqmM)
<button onclick="testDeviceOrientation()">Test Device Orientation</button>
function testDeviceOrientation() {
if (typeof DeviceOrientationEvent !== 'function') {
return setResult('DeviceOrientationEvent not detected')
}
if (typeof DeviceOrientationEvent.requestPermission !== 'function') {
return setResult('DeviceOrientationEvent.requestPermission not detected')
}
DeviceOrientationEvent.requestPermission().then(function(result) {
return setResult(result);
});
}
function setResult(result) {
document.getElementById('result').innerHTML = 'RESULT: ' + result;
}
Looks like drawmote.app has this working but the JS is compiled and it's taking me a while to reverse engineer their logic.
Redirect it to another subdomain that points to the same page.
I need to call logout function on the close of browser window gets close. It's working fine in Chrome not working in IE and Safari.
I have tried the following code:
window.onbeforeunload = function (e) {
// Your logic to prepare for 'Stay on this Page' goes here
var evtobj = window.event ? event : e;
if (evtobj == e) {
//firefox
if (!evtobj.clientY) {
//server call
}
}
else {
//IE
if (evtobj.clientY < 0) {
//server call
}
}
//return "Please click 'Stay on this Page' and we will give you candy";
};
I have tried a few other ways but they didn't work. Please advise.
There is something wrong in your design, you SHOULDN'T rely on a client-side hook to perform logout. There are one billion of reasons why that event could not be executed. Just limit the onbeforeunload event to execute informational content and not critical actions.
By the way:
Don't return in your beforeunload event! This creates some issue in IE
Use window.sessionStorage to make some data last until the user closes the tab
Use session cookies to store your user's sensitive data like as tokens, and check if a user is logged on the server, and not on the client
I have a WebExtension for Mozilla, which notifies me with the desktop notification function.
It works exactly how I want, but Firefox will close the notification automatically after X seconds. Is it possible to display the notification until the user clicks on it?
The thing I did is to close and reopen the notification every 5 seconds, so the user has to click on it to close it permanently.
This looks like this:
// This is the notification function
function notifyMeFunction() {
var notification = new Notification('Alert', {
icon: chrome.extension.getURL('icons.png'),
body: "New Notification",
tag: "DesktopNotification",
});
notification.onclick = function(event) {
notificationClicked = true;
}
notification.onclose = function(event) {
notificationClicked = true;
}
}
// Function which will self-open every 5 seconds
function notifyMe() {
if (notificationClicked == false) {
notifyMeFunction();
setTimeout(notifyMe, 5000);
} else {
notificationClicked = false;
}
}
Any ideas how to set the display time to something like "must interact"?
There is, currently (Firefox version <= 51.0a1), no method of indicating to the API that the user must interact with these notifications. Nor is there any way to specify for how long the notification is displayed to the user.
Note: You are using the Web Notifications API, not the WebExtensions chrome.notifications API. Neither has a way to require user interacting in Firefox.
From Chrome 50, Google Chrome does have an option to require that the user must interact with the notification: requireInteraction. Thus, at some point in time, Firefox will probably support such an option.
However, at least as of this point in time, the string requireInteraction does not exist in the Firefox source code.
Im implementing auth using this and am currently showing a loading icon in React when a user clicks the button to sign in and the auth2 account selection/login window shows.
However if a user closes the window, there doesnt seem to be any event fired i.e the signIn() function which returns a promise never resolves, I would have thought google would return an error for this promise if the window is closed. As a result there is no way for me to stop showing the loader icon and reshow the login menu.
I was wondering if anyone had a solution for this?
I try to modifiy my code that call Google OAuth 2.0 window.
You only have to add extra AJAX method that cover what is Google OAuth error result.
gapi.auth2.getAuthInstance().signIn()
Change it to this one,
gapi.auth2.getAuthInstance().signIn().then(function(response){
//If Google OAuth 2 works fine
console.log(response);
}, function(error){
//If Google OAuth 2 occured error
console.log(error);
if(error.error === 'popup_closed_by_user'){
alert('Oh Dude, Why you close authentication user window...!');
}
});
That's it...
For more detail about Google OAuth 2.0 information, you can visit this link.
https://developers.google.com/api-client-library/javascript/samples/samples#authorizing-and-making-authorized-requests
Sample code on JavaScript:
https://github.com/google/google-api-javascript-client/blob/master/samples/authSample.html
Although the API provides a mechanism for detecting when the user clicks the Deny button, there is not a built-in way for detecting that the user abruptly closed the popup window (or exited their web browser, shut down their computer, and so on). The Deny condition is provided in case you want to re-prompt the user with reduced scopes (e.g. you requested "email" but only need profile and will let the user proceed without giving you their email).
If the response from the sign-in callback contains the error, access_denied, it indicates the user clicked the deny button:
function onSignInCallback(authResult) {
if (authResult['error'] && authResult['error'] == 'access_denied') {
// User explicitly denied this application's requested scopes
}
}
You should be able to implement sign-in without detecting whether the window was closed; this is demonstrated in virtually all of the Google+ sample apps. In short, you should avoid using a spinner as you're doing and instead should hide authenticated UI until the user has successfully signed in.
It's not recommended you do this, but to implement detection of the pop-up closing, you could do something like override the global window.open call, then detect in window.unload or poll whether the window was closed without the user authenticating:
var lastOpenedWindow = undefined;
window.open = function (open) {
return function (url, name, features) {
// set name if missing here
name = name || "default_window_name";
lastOpenedWindow = open.call(window, url, name, features);
return lastOpenedWindow;
};
}(window.open);
var intervalHandle = undefined;
function detectClose() {
intervalHandle = setInterval(function(){
if (lastOpenedWindow && lastOpenedWindow.closed) {
// TODO: check user was !authenticated
console.log("Why did the window close without auth?");
window.clearInterval(intervalHandle);
}
}, 500);
}
Note that as I've implemented it, this mechanism is unreliable and subject to race conditions.
I'm building a facebook connect app to publish content to user's streams. In order to do that, I need to get extended publish_stream permission from the users. I'm using the function code to do so.
Check connection status
<input type="button" onclick="statusSubmit('Permission to publish : ');" value="Check connection status" />
<script type="text/javascript">
function statusSubmit(status)
{
facebook_prompt_permission('publish_stream', function(accepted)
{
if(accepted) {
// User (already) has permission
alert(status + 'already granted');
}
else
{
// User does not have permission
alert(status + ' not granted');
}
});
}
function facebook_prompt_permission(permission, callbackFunc)
{
// Check if user has permission, if not invoke dialog.
FB.ensureInit(function() {
FB.Connect.requireSession(function(){
//check is user already granted for this permission or not
FB.Facebook.apiClient.users_hasAppPermission(permission,
function(result) {
// prompt offline permission
if (result == 0) {
// render the permission dialog
FB.Connect.showPermissionDialog(permission,
function(result){
if (null == result)
alert('no permissons granted');
else
alert('permissions ' + result);
}, true, null);
} else {
// permission already granted.
callbackFunc(true);
}
});
});
});
}
</script>
After the permissions dialog is displayed and the user grants the permissions, there is a redirect my current page on my local development machine. I cannot seem to control this redirect behaviour through my settings. I have tried changing the "Post-Authorize Callback URL" to a publicly visible page, but it does not get called. Is there something I'm missing? I would like to either
Get the post-authorize callback URL to something that works OR
Even better if there is no redirection after the user grants
permissions. This option would be the best.
Thank you for any suggestions.
abronte, Thank you for your suggestion. I actually figured out that the path to xd_receiver.htm was incorrect, which was causing all the weird behavior. When I corrected that, things were OK. But the FB Javascript API is very flaky, we decided not to use it as the behavior is erratic. We will be switching to a server based solution in the future.
I believe that the post-authorize callback url that is set in the application settings only deals with within facebook canvas sort of stuff. What url is called after you authorize the app in facebook.
What I think the best solution is (and this is what i do) is to manually redirect the user after the extended permissions prompt is completed.
window.location = '/path/to/something';