I want to restrict some urls in a chrome packaged app, but when I try to use chrome.webRequest.onBeforeRequest.addListener in background.js in order to detect the call, I get error upon installing the app, 'webRequest' is only allowed for extensions and legacy packaged apps, but this is a packaged app."
My manifest is as below
...
"manifest_version": 2,
"app": {
"background": {
"scripts": ["background.js", "js/chromeUtility.js","js/customchromeserver/wsc-chrome.js"],
"persistent": false
}
},
"permissions": [
"webRequest",
"webRequestBlocking",
"*://www.xyz.com/*", // want to block this url
"identity",
"storage",
"webview",
...
How do I restrict a url in my chrome app , any suggestions ? Thanks
I could finaly do it since the url I want to block is loaded via webview, therefore I have checked it by using webview event listener for new window something like - webview.addEventListener('newwindow'), )
Related
I'm building a chrome extension and it includes a simple popup page that appears when you click on the extension's icon. This popup page consists of some simple HTML, CSS and jQuery code. Nothing fancy.
The JS seems to be running fine but the CSS hover, transition, and animation effects are extremely laggy (up to 5 seconds lag) when I interact with it on an external monitor.
Everything else runs perfectly fine and I can see that the JavaScript is executing as expected. It's just the above mentioned CSS rendering issues.
The funny thing is that if I drag the same browser window to my laptop's native screen, the issue is gone. Everything runs smoothly. Drag the same window over to any of my 2 external monitors and Bam! Lag city...
I've tested on my friend's computer and he has the same problem. Works fine on native screen, laggy on external monitors. So far it appears that the issue only occurs on Macs. Through the process of elimination, I know that the issue is not caused by the monitor itself and has nothing to do with the video input cables. I've only been able to observe this bug on external monitors connected to my Macbook Pro (Early 2015) and my friend's Macbook Pro (Early 2014).
Things I have tried (and didn't help):
Disabling "hardware acceleration" via Chrome settings
Restoring Chrome to default settings
Monitoring system performance (CPU and Memory usage are both well below limits)
Monitoring Chrome Task Manager (The extension is using minimal memory and no notable CPU usage difference between the laggy and non-laggy tests)
Toggling a bunch of settings in chrome://flags
Switching out various cables (HTMI, DVI, and VGA)
Curious to know if anyone else has run into similar issues? This weird external monitor lag issue has been bugging me all week and I'm all out of ideas.
Github repo to demo project -> https://github.com/peachteaboba/chrome_extension_bug_demo
------------------------- Update -------------------------
I've pinpointed the source cause of the bug. Apparently if you include a background.js file in the manifest.json then the popup lags. If you do not include a background script then the lag is gone.
manifest.json (laggy version)
{
"manifest_version": 2,
"name": "Chrome Extension Bug Demo v2",
"description": "Chrome Extension Bug Demo v2",
"version": "2.00",
"author": "",
"browser_action": {
"default_icon": "images/bug.png",
"default_title": "Chrome Extension Bug Demo v2",
"default_popup": "popup.html"
},
"chrome_url_overrides": {},
"permissions": [
"storage",
"tabs"
],
"background": {
"scripts": [
"js/background.js"
]
},
"web_accessible_resources": [
"script.js"
],
"externally_connectable": {
"matches": [
"http://*/*",
"https://*/*"
],
"accept_tls_channel_id": true
}
}
manifest.json (non-laggy version)
{
"manifest_version": 2,
"name": "Chrome Extension Bug Demo v2",
"description": "Chrome Extension Bug Demo v2",
"version": "2.00",
"author": "",
"browser_action": {
"default_icon": "images/bug.png",
"default_title": "Chrome Extension Bug Demo v2",
"default_popup": "popup.html"
},
"chrome_url_overrides": {},
"permissions": [
"storage",
"tabs"
],
"background": {
"scripts": [
]
},
"web_accessible_resources": [
"script.js"
],
"externally_connectable": {
"matches": [
"http://*/*",
"https://*/*"
],
"accept_tls_channel_id": true
}
}
The only change made was removing "js/background.js" from the background scrips section. The actual background.js file is empty, so even including this empty script will trigger the Chrome bug.
There is a Chromium bug ticket open for this issue. You can view that via this link: https://bugs.chromium.org/p/chromium/issues/detail?id=971701
We faced this issue in production for our Chrome Extension at usebubbles.com and worked around it by forcing the popup to repaint while opened on a secondary monitor on MacOS.
Simply add the following to the top of a javascript file included from your popup.html:
/**
* Temporary workaround for secondary monitors on MacOS where redraws don't happen
* #See https://bugs.chromium.org/p/chromium/issues/detail?id=971701
*/
if (
// From testing the following conditions seem to indicate that the popup was opened on a secondary monitor
window.screenLeft < 0 ||
window.screenTop < 0 ||
window.screenLeft > window.screen.width ||
window.screenTop > window.screen.height
) {
chrome.runtime.getPlatformInfo(function (info) {
if (info.os === 'mac') {
const fontFaceSheet = new CSSStyleSheet()
fontFaceSheet.insertRule(`
#keyframes redraw {
0% {
opacity: 1;
}
100% {
opacity: .99;
}
}
`)
fontFaceSheet.insertRule(`
html {
animation: redraw 1s linear infinite;
}
`)
document.adoptedStyleSheets = [
...document.adoptedStyleSheets,
fontFaceSheet,
]
}
})
}
If you are in a Dual monitor environment and face Input lag issues, it is related to your physical window size.
Do not attempt to try it on your big monitor, but, instead, try your chrome extension on your laptop(your MacBook) device itself. You will see it will work on your mac, but not on your connected big screen.
I did a Chrome extension, successfully published it on Chrome Webstore, a friend installed it yesterday, and today, when launching Chrome, he sees Unsupported extensions disabled:
What are the usual reasons for that? How to fix it?
Note: the extension is just a minimalist:
{
"name": "...",
"version": "1.0",
"description": "...",
"content_scripts": [
{
"css": ["fix.css"],
"matches": ["http://*/*", "https://*/*"],
"run_at": "document_end"
}
],
"manifest_version": 2,
"permissions": ["*://*/*"]
}
and a fix.css that modifies the design of certain elements. Nothing else is in the extension. It is still accepted/published on the Chrome Webstore.
This is because extension is not published in Chrome webstore. Perhaps installing Chromium browser can help. It should allow to use non-webstore extensions.
There is also bit complexated way to use pre-installed extension described here.
As recommended in this page:
Try this removal procedure ... http://malwaretips.com/blogs/remove-discount-buddy-virus/
Try running the new Google Software Removal Tool ..(Windows Only). Do Browser Reset at end.
You may also check this Important: Updates on Chrome Extensions.
I made a simple chrome extension:
manifest.json:
{
"name": "Layout VS Design",
"version": "1",
"description": "Enter the url of a image with your design at 100%",
"background_page": "index.html",
"browser_action": {
"name": "Manipulate DOM",
"icons": ["icon.png"],
"default_icon": "icon.png"
},
"content_scripts": [ {
"js": [ "jquery.min.js", "js.js" ],
"matches": [ "http://*/*", "https://*/*"]
}]
}
The thing is that chrome won't let me install it:
The thing is I have no idea where to set this number, Any idea what can I try?
The first thing I see is that your background_page isn't formatted properly. It should be
{ ...
"background": {
"page": "index.html"
},
...
}
If you manifest.json file isn't formatted correctly, Chrome will reject the extension.
You can read more about the manifest formatting in the Manifest File Format documentation from Google.
Update
Another SO post detailed how Chrome looks for a "magic number" at the top of a .crx file. But, if you're hosting locally, you can install extensions in a simpler manner.
Save your manifest.json and background.html to a directory (the name doesn't matter)
Go to chrome:extensions
Make sure "Developer Mode" is checked at the top
Click "Load unpacked extension..."
Select the directory with your background and manifest files to install on Chrome.
go to extensions page
check developer options
click on pack extension
set root directory (folder in which your images and manifest file
exist)
pack extension
now disable developer options
go to root directory (do not open root directory saying this only so
that you could easily find file otherwise you can open it)
you will see a .crx file just open it with chrome (e.g. drag and drop this file onto the chrome://extensions/ page)
click on continue (will come at the bottom of chrome window)
Your Chrome browser is modified like you wanted
We developed a Chrome extension and it is working fine for websites with out https protocol. But, it is not loading on sites running with https protocol.
Are there any work around to fix this issue?
In your manifest file, the matches in content_scripts should be like this:
"content_scripts": [
{
"matches": [
"http://*/",
"https://*/"
],
...
},
...
]
Since it seems none exist, I'm trying to make a chrome extension to set my New Tab page to a local .html file. Here's what I have so far:
{
"name": "MyHomepage",
"version": "1.0",
"manifest_version": 2,
"description": "Set an HTML page as your New Tab page",
"browser_action": {
"default_icon": "icon.png"
},
"chrome_url_overrides" : {
"newtab": "/Users/shortname/Documents/Home.html"
}
}
However, when I load a new page, it gives me this:
No webpage was found for the web address: chrome-extension://(gibberish)//Users/shortname/Documents/Home.html
It seems Chrome is sandboxing my extension somehow. Is there a way to let it access my local file?
Chrome's extension API does not allow for direct reading or writing from/to disk.
If you want to do that you'll have to use a NPAPI plugin in your extension:
http://code.google.com/chrome/extensions/npapi.html
You can use Native Messaging instead of NPAPI https://developer.chrome.com/extensions/messaging#native-messaging