Chrome API Alarm stops after page refresh - javascript

Reading around, I was under the impression that the Chrome alarm continues to work even after Chrome is closed, page refreshed etc. From one of the Google results:
With the Chrome alarm APIs, you can set an alarm that lasts as long as
the app is installed, even if its background page goes inactive.
My problem is that I have setup a Chrome alarm in my options.js page for a Chrome Extension. The alarm is created (chrome.alarms.create) when the options page is saved.
The alarm works if I keep my page open. However, if I reload the page (options.html), I don't get the alarms anymore.
Here is part of my options.js
$('#save-options-button').on('click', function() {
//Clears existing alarm
chrome.alarms.clearAll();
//Create alarm
chrome.alarms.create("fetchAlarm", {
delayInMinutes: 1,
periodInMinutes: 1
});
chrome.alarms.onAlarm.addListener(function(alarm) {
console.log("Got an alarm!", alarm);
});
});

I guess you are quoting the Chrome Apps documentation, that's why it gets confusing.
What was meant is that event pages (a type of background page) will be woken up to serve an alarm event even if they were unloaded for being idle.
This applies only to event/background pages. Chrome would not randomly open a page only because an event that the page listened to in the past happened. As such, you should not put actual event listener logic into UI pages (options, popup, etc.)
In your case, refreshing the page makes the JS context that contained the listener to be destroyed along with it, and your logic only adds a listener after a click. Even if you added that addListener to the top level code instead, it would only function as long as the page is open.
So, you will need to add a background page to service that event (the actual listener).
A background page is normally always ready to answer events. Event pages are special in that Chrome remembers which events should trigger their load and doesn't keep them loaded. You can read more about it in another answer of mine.

Related

Best way to detect browser window changes like go back, url change, reload, close event

So I am working on a testing application and I need to call a finsihTheTest() function (i.e. this function finishes the test by saving answers, time and other information) whenever following conditions occur:
User tries to reload page.
User tries to go back from the page.
User tries to close the tab.
User tries to close the browser window.
User goes to another url.
If anything happens that closes the page like laptop/PC shutdown, internet lost or anything else.
What I exactly want to do is, if once a user starts the test and by any mean he attempts to leave I want to save his state. Which is being done by the function finishTheTest().
I got a clue but it didn't work:
function UnLoadWindow() {
return 'We strongly recommends NOT closing this window yet.'
}
window.onbeforeunload = UnLoadWindow;
To get the full results for your cases there's many things you should now on how browsers react on many scenarios.
To understand more please read this section :
Especially on mobile, the unload event is not reliably fired. For example, the unload event is not fired at all in the following scenario:
A mobile user visits your page.
The user then switches to a different app.
Later, the user closes the browser from the app manager.
Also, the unload event is not compatible with the back/forward cache (bfcache), because many pages using this event assume that the page will not continue to exist after the event is fired. To combat this, some browsers (such as Firefox) will not place pages in the bfcache if they have unload listeners, and this is bad for performance. Others, such as Chrome, will not fire the unload when a user navigates away.
If you're specifically trying to detect page unload events, it's best to listen for the pagehide event.
window.addEventListener('pagehide', function(event) {
document.cookie = "saveData=test"
},false)
This way you can save your user current data and reload it on next page window load event

Which JS events apart from `click` will successfully activate the Fullscreen API?

I've been refactoring some javascript.
Previously, I had an HTML element open to Fullscreen when the user clicked on another element.
Now clicking the latter element initiates a server-side verification, instead.
Once the server-side verification check passes, the page reloads with extra data confirming the user is verified.
N.B. When the page reloads, it does so with a non-negligible amount of extra markup, styles, scripts and vectors. The reason I am re-factoring in the first place is to avoid the need to download all these extra assets (and keep them in the background, on standby) unless and until the user authenticates themselves
The first thing I discovered is that I cannot have the page reload and then have the HTML element immediately open to Fullscreen, because - and this seems entirely reasonable from a UX perspective, Firefox reports:
Request for fullscreen was denied because Element.requestFullscreen() was not called from inside a short running user-generated event handler.
Essentially, unless the user pro-actively interacts with the page, the Fullscreen API will not run.
(In this scenario, the user pro-actively interacted with the page before reload, which is not the same thing.)
So, I thought about it and then added:
document.body.addEventListener('mousemove', () => myElement.requestFullscreen(), {once: true});
Nope. The Fullscreen API still doesn't activate.
To check that I wasn't making an elementary error somewhere else, I tried:
document.body.addEventListener('click', () => myElement.requestFullscreen(), {once: true});
Which does work.
So: some user-interactions will successfully fire the Fullscreen API and others won't.
I have searched through the WHAT-WG HTML Spec but I cannot find a list of events which represent explicit and pro-active user-interactions on a webpage.
Does such a list exist?
Which other events apart from click will successfully activate the Fullscreen API?
Which JS events apart from click will successfully activate the Fullscreen API?
A small number of events will successfully activate the Fullscreen API.
Almost all of these events either imply a user-click or directly reference one:
change
click
contextmenu
dblclick
mouseup
pointerup
reset
submit
touchend
Further to the list of click-based events above, the Fullscreen API may also be activated via:
ScreenOrientation.onchange
Source:
https://www.aworkinprogress.dev/request-fullscreen

A bit confused about the "agenda" of a Chrome extension

So, I wrote a few extensions, most disposable and one hopefully viable.
I'm still a bit confused about the "agenda", of "schedule" or whatchacallit, i.e. the order in which things happen, and the places where they live.
For example, I am writing a new one that shall do the following :
a browser action presents the user with a menu of 3 items
two of those items trigger actions to be executed immediately, while the third lauches a process that is to run undercover for an extended period (namely polling a certain web page at an interval, said web page needing not to be loaded in any visible tab or window).
Naturally I'd be tempted to assume that the long-term is to live in the background.js.
Now, I understand that the pop-up menu is an HTML document in its own right, living its life in its own bubble. It shall disappear right after the user cliked on an item, thereby taking its context with it to its grave. Right now I'm at a bit of a loss trying to figure out how it can trigger a background process.
Notwithstanding, I don't quite grasp what brings the background.js to life, even less so when it is specified as non persistent as is recommended.
Naturally, I'll RTFM again, but if you fellows could dumb this down to my poor level of understanding, I'd be so happy ...
Maybe as you said, you would need to RTFM again..
Background Page runs in the extension process and exists for the lifetime of your extension, until your extension is removed or the browser process terminates.
While Event Page, what chrome has recommended to use, is loaded only when they are needed. Take a look at Lifetime part, the following are some example that will cause the event page to load:
The app or extension is first installed or is updated to a new version (in order to register for events).
The event page was listening for an event, and the event is dispatched.
A content script or other extension sends a message.
Another view in the extension (for example, a popup) calls runtime.getBackgroundPage.
As for your question, 'how it can trigger a background process', if there are no events to catch or message to pass, you can just call runtime.getBackgroundPage to load the event page.

Chrome executing all JS again on browser back button

I am developing a web application. And I wrote some JS script to be executed on document ready. But in chrome when we click on back button and go back to previous page it is executing all the js script again. But when I use same on firefox it do not execute the JS.
I have an accordion on a page and when user open any accordion and go on one of the link under the accordion and after that if again clicks the back button on the accordion page chrome is closing all the accordions as I have written the script to close all these on document ready. But firefox do not close.
Is there any way to fix this with javascript? So that I can put any condition like if(history.forward.length < 1){ do this....}
You can use the pageshow event to guarantee you always detect navigation to a particular page, regardless of whether the user presses the back/forward button or selects a link, and regardless of which browser is being used.
Then you can perform checks regarding the state of UI and perform logic as required (i.e. modify UI, prevent execution of additional JS).
window.addEventListener('pageshow', function(event) {
// check state of UI, etc.
});
The solution that came to my mind is using sessionStorage to know if it is a first time loading or not. Or even better, you can keep state of your accordions in session storage so it always be the way the user want.
In my case, the iframe was a hidden iframe (width and height zero).
This iframe is just an workaround from legacy system, developed 12 years ago. But still using nowadays on current application.
To solve it, i just redirected the page loaded into iframe to the blank page.
Example:
page_loaded_into_iframe.php
<?php
//do the php stuffs
?>
<script>
alert("hello world");
location.href = "about:blank"; // here, where the the magic happens!
</script>
Once pressed the "back button", the browser will reload a blank page.
Be aware that this might be not applicable if your case is not similar to mine.
In the Chrome Extension you can use the function:
chrome.webNavigation.onCommitted.addListener(function callback)
and in the callback function you may take a look to the arguments:
transitionType + transitionQualifiers
to look for:
"forward_back" The user used the Forward or Back button to initiate the navigation.
For deatils see chrome.webNavigation
Of course, this event can be communicated to the content script with the usual message model (refer to: Message Passing

Javascript event on tab or window open

I'm developing an online production management software and I need to keep track of which pages of the app the user has open.
I'm currently using body onload and onunload -events to modify a page specific key/value -pair in local storage to "true" or "false" which I then use to tell if the user has the page open or not.
The problem is that when I do it like this and the user has multiple instances of the same page open and he closes one of them, then the value of the key in the local storage changes to "false" even when there are still other instances open.
I guess I could try to do this with a kind of a counter which is incremented on the pages body onload event and then decremented on the body onunload event.
But then there is the problem that the body onload event fires also when refreshing the page so then the user could have none of the pages open and the app would still think that there are pages open.
What would be a good way to track wich pages of the site or app the user has open?.

Categories