I am experiencing some strange behavior from a Chrome extension that I am developing. The extension is a fork of the Mozilla PDF.JS chrome extension, which provides a custom PDF reader that overrides the default Chrome one.
The problem is that when I have a PDF file open using the extension in an inactive tab and I have a different tab activated, sometimes the inactive PDF tab will suddenly reload and forcibly switch the browser's active tab back to the PDF. I have noticed that it happens most often when my computer is running low on available memory.
For example: Tab A is displaying https://www.example.com/test.pdf via the extension, and Tab B is displaying https://www.example.com/home.html like any regular chrome tab. The user is actively using Tab B when suddenly Tab A reloads and changes the current tab to Tab A.
This is very poor design. I do not want my extension suddenly changing the user's current tab without their consent. Any ideas of how to approach this problem? I haven't been able to find any resources online about this. So far I have made only minimal changes to the extension. The main difference so far is that I updated the manifest.json (see below) from V2 to V3. Outside of that I haven't changed much. I don't mind if the extension reloads itself when resources are low, but it can't be changing the user's current tab against their will.
manifest.json
{
"manifest_version": 3,
"name": "PDF Viewer",
"version": "2.16.0",
"description": "Uses HTML5 to display PDF files directly in the browser.",
"icons": {
"128": "icon128.png",
"48": "icon48.png",
"16": "icon16.png"
},
...
Related
I have a browser extension for Chrome and Firefox and in the manifest.json I've defined a page to load on new tabs:
"chrome_url_overrides": {
"newtab": "page.html"
},
In Firefox this shows my page in new tabs but not on the first tab or in new windows. In Chrome this is no issue and the page is shown for the first tab, new tabs and new windows.
I read about the homepage setting, which would be used like this:
"chrome_settings_overrides": {
"homepage": "page.html"
},
As it resides in a different key (chrome_settings_overrides) I get the feeling it behaves differently as well but I can't find much about the differences or similarities between these two in the docs.
The Firefox docs actually links these two features together by stating you might need the other. (Firefox newtab and homepage, Chrome newtab and homepage.) Also I found this issue in the Firefox bugtracker (https://bugzilla.mozilla.org/show_bug.cgi?id=1341458) where they're moving the homepage setting from chrome_url_overrides to chrome_settings_overrides, so that implies they work similar.
Update: I tried making this change and it breaks the extension in Firefox without specific explanation and gives a warning in Chrome stating that the homepage should be a url.
Does someone know how to make an extention take over the first/new window in Firefox?
And optionally:
if there's any differences between these two features?
why Chrome seems to not need the homepage to be defined and uses the newtab setting for the first tab and new windows as well?
Any changes of using this? (there is a index parameter for the position) https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/create
I've created a service-worker and manifest.json file in order to display an 'add to home screen' Web App Install Banner for Chrome Browser Users.
It is not working as intended.
Here is my manifest.json file
{
"name": "MySite",
"short_name": "Mysite",
"start_url": "./?utm_source=homescreen",
"icons": [{
"src": "assets/cacheable/images/shortcut/120x120.png",
"sizes": "128x128",
"type": "image/png"
}, {
"src": "assets/cacheable/images/shortcut/142x142.png",
"sizes": "142x142",
"type": "image/png"
}, {
"src": "assets/cacheable/images/shortcut/192x192.png",
"sizes": "192x192",
"type": "image/png"
}, {
"src": "assets/cacheable/images/shortcut/192x192.png",
"sizes": "384x384",
"type": "image/png"
}],
"orientation": "portrait" ,
"background_color": "#fff",
"display": "standalone",
"theme_color": "#fff"
}
Please let me know if I forgot to add anything?
First, let's check if your manifest fulfills the requirements for showing Web App Install Banners.
Requirements
Full (current) requirements for showing Web App Install Banners are*:
Have a web app manifest file with:
a short_name
a name (used in the
banner prompt)
a 144x144 png icon
a start_url that loads
Is served over HTTPS (a requirement for using service worker).
Is visited at least twice, with at least five minutes between visits.
Reference
Okay, so for now let's assume this is all valid. Let's move on to testing.
Testing
To test if you've installed it correctly, you can try the following steps:
Open Chrome DevTools,
Go to the Application panel
Go to the Manifest tab
Click Add to homescreen.
A prompt should now show on top of your browser asking if you want to add the url to your things (on Chrome desktop).
Troubleshooting
If after testing you are getting the following error in your console:
No matching service worker detected. You may need to reload the page, or check that the service worker for the current page also controls the start URL from the manifest
Then please make sure that 1. Your service worker is functioning properly and without errors, and 2. Your start_url matches an actual url of your website that loads. Else, you will never get the prompt to show!
Additionally,
Do note that users (and you!) can also add to the home screen manually through the the (Android) Chrome menu. It is not required to wait for the prompt! I add a lot of websites I tend to use daily to my homescreen, and I hardly ever see a banner!
* Do note that these requirements could change from time to time (they have before!). An update to 'Add to home screen' coming in 2017 has already been announced here
** Also note that these requirements differ significantly from native app install prompts.**
your manifest.json seems good enough.
and the above mentioned points by #Extricate are correct and perfect.
So the next question is have you implemented service-worker for your app?
I read somewhere that an empty service-worker file would work but when I tried an empty implementation of service-worker, it said that
'Site cannot be installed: the page does not work offline'
So I suppose that latest chrome version would not be supporting the A2HS prompt for APP INSTALL BANNERS if you service-worker dont support offline working.
You can try going to Basic web app prompt , go to devtools in chrome, navigate to Application tab.
There you will find manifest.json. On LHS of the manifest file, you can see the ADD TO HOME SCREEN. When you click, it will print
'Site cannot be installed: the page does not work offline'
PFA screenshot for same
In your service worker js file add this one line of code:
self.addEventListener('fetch', function(event) {});
May be usefull, as had similar issue. The Install infobar appeared once and never again.
From Developers Google
The mini-infobar will appear when the site meets the criteria, and
once dismissed by the user, it will not appear again until a
sufficient amount of time has passed (currently 3 months).
Steps to reproduce the problem:
Open the dev tools
Select the "Sources" tab
Open any Javascript file in the Sources tab
After a short (1 to 2 second) delay, the following message appears: "Serving from the file system? Add your files into the workspace"
Dismiss the message by clicking the "X" on the right side
Refresh the page
After a short delay, the message appears again
I don't want to use the workspaces feature, then I should be able to disable these constant, repetitive, annoying messages. Ideally, there would be a dev tool setting to turn off workspace prompts.
My Chrome version: 42.0.2311.135 (64-bit) (Google Chrome is up to date)
You can disable this message permanently by clicking on "never show" as shown in the screenshot below.
This is Developer tools opened in a separate window. I am using latest chrome (v55 as of now), but I have observed that clicking "never show" permanently hides the message in a lot other earlier versions of chrome as well.
P.S.: I had to blur the code as it belongs to the company I am working for.
I have an extension that has the following files:
content.js, background.js, manifest.json, mystyles.css, jquery-2.0.3.js and icon.png.
I can set breakpoints in the content.js file via the Chrome Debug Tool via the "Sources" tab and via the "Content Scripts" tab. My problem is that I can't find a reference to the "background.js" file, so I can set a breakpoint in it. Can someone tell me what I am overlooking or doing wrong?
References:
I have watched the Chrome Debug Video on YouTube.
I have read the Chrome Tutorial on Debugging.
If you open up a new tab and go to chrome://extensions, you will see a list of installed plugins, including your own. Next to your plugin, there will be a link to "Inspect Views" pointing to a background.html page or a generated one in your case. This will launch a new debug window in Chrome that will allow you to browse to your background.js file and set breakpoints (by clicking on the line number)!
I have an extension with a background page, and by default this causes Chrome to persist after you close all windows, and puts the Chrome icon in the system-tray. I would like to avoid this -- I do not want my extension to cause the Chrome process to persist after closing all Chrome windows, nor do I want to cause Chrome to appear in the systray.
According to the only docs I could find on this indicates that the user can set this option globally across all extensions, but that isn't what I'm trying to do. I'd like the extension to be unassuming / unobtrusive, and don't want to change the user's browser behavior. Does anyone know how to accomplish this while retaining the ability to have a background page?
UPDATE
With manifest version 2 you can now run event pages that are not persistent. Event pages are very similar to background pages but are only loaded when needed by the extension.
Example from the event pages doc on setting a non persistent event script in your manifest:
{
"name": "My extension",
...
"background": {
"scripts": ["eventPage.js"],
"persistent": false
},
...
}
Here is a tutorial on migrating your Chrome extension to manifest version 2.
OLD ANSWER
Currently, if your extension has a background defined in the manifest.json file, it will run before Chrome is launched and continue after all windows of Chrome are closed. That is unless the user changes their settings like you mentioned. There may be future versions of Google Chrome that allow for different functionality but you, the developer, won't be able to get around this issue at this time.
An excerpt from the background manifest docs
Makes Chrome start up early and and shut down late, so that apps and extensions can have a longer life.
When any installed hosted app, packaged app, or extension has "background" permission, Chrome runs (invisibly) as soon as the user logs into their computer—before the user launches Chrome. The "background" permission also makes Chrome continue running (even after its last window is closed) until the user explicitly quits Chrome.