I'm developing an extension with chrome.notifications would like to set a time for closing the notification, how can I do this?
Chrome automatically hides the notification. How long it stays on screen depends on the priority attribute. Note that everywhere except Chrome OS the hidden notification is effectively closed, as the Notification Center was removed.
It's possible to keep the notification shown, but you'll have to resort to dirty tricks. If you don't want to do it the hard way, consider using Web Notifications instead - they will not be hidden.
Update: Both chrome.notifications and Web Notifications APIs now implement a boolean flag requireInteraction that defines whether Chrome will fade the notification away automatically or not.
You can still manually close (i.e., remove completely) the notification by calling chrome.notifications.clear() with the notification ID.
To schedule something, you can either use DOM intervals, or chrome.alarms API.
I'm using this in my project
var opt = {type, title, message, etc....}
chrome.notifications.create("", opt, function(id) {
timer = setTimeout(function(){chrome.notifications.clear(id);}, 2000);
});
notification is closed after 2 sec (2000 ms)
Related
hi im using laravel 8 and my software is pos ..
everything working so good but i have big problem ..
thats sometimes the cashier can refresh the page when the customer is gone without save the invoice
..
so what i did is this ..
document.addEventListener('keydown', (e) => {
e = e || window.event;
if(e.keyCode == 116)
{
var is_admin = $("#is_admin").val();
if(is_admin != 1)
{
e.preventDefault();
// this code here will not allow f5 to work
}
}
});
but the cashiers goes to the address bar and hit enter and like that he refresh the page
also sometimes they hit the refresh button beside url bar
so i start chrome in kisok mode in full screen
but the problem thats he can move the mouse to the top of the browser and the url bar will show again and he can do refresh page ..
so the solution for my problem is there any way to set password in chrome when refresh the page or close the chrome or is there any way to start chrome without close bar and url bar in kisok mode
thanks ..
Based on my research I didn't find anything related to setting a password in chrome for closing, instead, I have other solutions that may help you by considering this closing/refreshing issue happens accidentally.
#1st Solution - Closure Extension
https://chrome.google.com/webstore/detail/closure/jjagagcgljmlnihcilbpbfcglnopepjb
a very simple extension that works by locking the current browser tab. Click the toolbar icon or right-click on a page and select “Confirm Closure”. The favicon for the website in the current tab will turn into a padlock.
if the cashier clicked on the refresh button or the closing button a confirmation popup will show up.
#2nd Solution - Disable Close Button
checkout these 5 software that claims to prevent accidental closing of software by disabling the close button
https://www.raymond.cc/blog/prevent-program-closing-disabling-close-button/
#3rd Solution - Saving Draft.
The last solution I have is a workaround you can make by using
window.addEventListener('beforeunload', function (e) {
// saving current invoice in localstorage to be retrieved later
});
// check this answer
// https://stackoverflow.com/questions/13443503/run-javascript-code-on-window-close-or-page-refresh
beforeunload event, so you can save a draft of the current invoice in locale storage before closing the window, but you are should be very aware of how to manage these drafts, when to retrieve them, and when to clean them.
Also, you can use service workers if you choose this kind of solution.
Again, this all about if the cashier accidentally makes this behavior, which I think he must be aware of what he is doing, so you are making your validations as you can to prevent such behavior and make your system as robust as possible, I encourage you to think of this problem in a technical way then you should take the 3rd solution, and for the client just offer him the other 2 solutions which I see they will work well, otherwise, if the client wants to make something wrong in purpose then it will be his responsibility.
I am making a chrome extension that fetched JSON data from CoinMarketCap.com API and currently I have it running in the background script. I'm not 100% sure what the purpose of the page is really. I was wondering if I could simply fetch the data from the popup script after I click a button within my popup?
Each button represents a different coin. I basically want to get the price of a chosen coin and display it on whatever page the user is on when they double click the coin in a text article. Eventually I want to make it so you can double click any coin and have it show a live price conversion while you're on the web-page.
The point of a background page is to be always available (running if persistent: true, woken up / recreated for registered events if persistent: false).
A popup's lifetime is determined by its visibility. The moment the user clicks away and closes it, the page is closed (as if the tab with it was closed), so it can no longer process any events and its state is lost.
As long as:
The data you need fetched is to be received/processed while the popup is open
Any state you need to persist between popups being shown can be stored in chrome.storage
Then you don't need the background page to do the fetching. Popup page has the same level of access to Chrome APIs.
However, consider this scenario: suppose you want the data to be ready as soon as popup is opened (at least, you want it to be fresher than "since last time"). You may want to do periodic updates even while the popup is closed to refresh the data. You can only do that reliably with a background page (and, say, chrome.alarms API). Then you can cache the latest available data in chrome.storage and use that in the popup.
Background pages have their uses as some code that can run periodically regardless of user actions, and to be able to always react to events.
According to Changes to Cross-Origin Requests in Chrome Extension Content Scripts now you have to do your fetches in Background Script. Not in Content Script.
I am building a system to send web push notifications with chrome. When someone receives my push notification on their desktop PC they see the notification for about 10 seconds. If they don't click on the notification it will then disappear after about 10 seconds.
I see other websites sending push notifications that do not disappear. I believe there is some setting I am not using to make my messages stay on the screen until clicked or exited. Does anyone know this setting or parameter?
It looks like you need to use the 'requireInteraction' option creating the notification in your service worker. Just set it to 'true' to say the browser you need the user interaction. Here is how you do this.
...in your service worker script when you create a notification:
self.addEventListener('push', function(e) {
var notification = self.registration.showNotification(
"Hi! Click me!",
{
requireInteraction: true,
body: "I'm not going to disappear"
}
);
e.waitUntil(notification);
});
Also don't forget to close it on click event:
...later in the service worker script:
self.addEventListener('notificationclick', function(e) {
e.preventDefault();
e.notification.close();
// Do click actions
});
Browser comparability: unfortunately not everybody supports this option yet: Firefox doesn't. See the Mozilla reference for details: https://developer.mozilla.org/en-US/docs/Web/API/notification/requireInteraction
But it works fine in Chrome.
You may want to try the suggested solution in this SO post which consists the following steps:
Register listeners for all the events mentioned in chrome.notifications.
Register a timeout after a few seconds (e.g. 30) -after the notification is hidden- that will delete and re-create the notification (so it effectively stays visible on the screen.
If any of the listeners set on step 1 fires, it means the user interracted with the notification, so cancel the timeout (you don't need to re-create the notification).
See the post for more information.
I am developing a web site where users can change settings which they have to confirm before taking effect.
The confirmation is done by a link I send them via E-Mail. In the HTML of the website I use this little snippet:
<script type="text/javascript">window.name="mysite";</script>
And in the HTML emails I use
Click me
But Chrome is always opening new tabs instead of opening them all in one.
Is this even possible or is it forbidden for some reasons?
Webmail platforms such as Gmail tend to modify some of the HTML code of an email due to security reasons.
They obviously remove any javascript code the email could have. But they also change (or add if none) the target property of every anchor element and set them to target="_blank" in order to avoid the user to be taken out of Gmail (in this case).
Unfortunately every webmail platform has their own behavior, therefore, what you want to do is not gonna work on every webmail platform.
If what you want to do is prevent the user from having multiple tabs of the same page opened, (*please refer to Update 1) it comes to mind you could use web sockets to close the previous tab once the user enters in the URL sent by email. Have a look at socket.io for example.
Update 1
There's no way to do this using WebSockets. There's no possible way to close a window that wasn't opened using javascript, and it can only be closed by it's parents.
That is a very interesting idea. I like it. Alas, it appears that, in modern browsers, you can no longer close a window you didn't open through javascript. So if you aren't allowed to run javascript in the email, the best you can do is to redirect the original page to a "thank you" page and leave it hanging around in the browser's tab (but no longer waiting on conformation). Like this:
PleaseConfirm.html:
window.name="need_redirected";
Confirm.html:
var w = window.open("", "need_redirected");
if (w)
w.location="ThankYou.html";
Of course, for old IE, I'd still try to close the old window in ThankYou.html:
window.top.close();
You can still try to set the target, of course, just in case it works, and you can always try putting an onclick attribute on your tag for the same reason:
click here
But that seems to be the best you can do. Bummer.
Neither of the other two answers work, but this one probably will:
In the initial tab, listen for an onstorage event, with a certain key being created, e.g. "userHasConfirmedEmail". When the event occurs, window.top.close().
In the new tab, create that key.
Credit goes to Tomas and his answer.
I am looking for a way to determine a given tab's opener (parent tab) within a Google Chrome extension.
I've looked at the documention for Tab but there doesn't really seem to be anything that would yield this information. http://code.google.com/chrome/extensions/tabs.html
I've tried injecting this content script into pages (thinking I could pass the value to my background page):
alert(window.opener);
.. but it just yields null.
The best thing I've come up with so far is to keep track of the currently focused tab, and whenever a new tab is created, just assume that the focused tab is the opener/parent of the new tab. I believe this would de facto identify the parent tab correctly most of the time since background tabs rarely (are allowed to) open new pages. However, it seems kludgey and potentially inaccurate at times -- for example, if another extension opened a new tab, this method may misidentify the new tab's opener.
Update: it is now possible to reliably determine a tab's opener tab within a Chrome extension natively using the newly added webNavigation API, and specifically by hooking the onCreatedNavigationTarget event.
https://code.google.com/chrome/extensions/trunk/webNavigation.html
Chrome has added an experimental extension API which can accomplish this -- specifically webNavigation.onBeforeRetarget. http://code.google.com/chrome/extensions/experimental.webNavigation.html
However since this is still experimental (not usable in Chrome stable versions or releasable on the Chrome Web Store) I have ended up using another approach.
Basically:
In content_script.js:
chrome.extension.sendRequest({
request: {
op: "pageLoadStarted",
url: document.location.href,
referrer: document.referrer
}
});
In background.html:
chrome.extension.onRequest.addListener(function(request, sender, sendResponse) {
console.log('onRequest: ' + JSON.stringify(request));
console.log(JSON.stringify(sender));
});
This approach allows me to obtain the referrer of a tab, which I can then correlate with an existing tab's url. This isn't always a one-to-one mapping, so I do some additional magic such as preferring the currently selected tab as the opener if its url matches the new tab's referrer.
This really is just a hack to approximate the functionality that would be provided more simply and accurately by webNavigation.onBeforeRetarget or window.opener.
Further investigation has revealed that onCreatedNavigationTarget() does not always fire when you think it would to indicate an opener-opened relationship.
An additional hint can sometimes be found in the Tab object returned by chrome.tabs.onCreated/onUpdated in the .openerTabId parameter.
A comprehensive solution will probably have to rely on multiple of the methods described in these answers.
port.onMessage.addListener(
function(msg) {
var tabid = port.sender.tab.openerTabId;
console.log("Received message from tab that was opened by tab id : " + tabid);
// reliably shows the tab id of the tab that opened
// the tab sending the message
});