I am trying to access all stylesheets from a Chrome extension using the Remote debugging protocol. According to https://chromedevtools.github.io/debugger-protocol-viewer/CSS/ there should be a method for this:
A client can also discover all the existing stylesheets with the
getAllStyleSheets() method
However I was unable to execute this. Is this implemented? Is there another way of accessing the CSSOM from a background script
It was implemented, but has been since removed.
DevTools: [CSS] remove getAllStylesheets method from protocol
This patch removes getAllStylesheets method from protocol. Instead,
clients should track styleSheetAdded/styleSheetRemoved events to
maintain actual stylesheet set.
Related
We want to use a Service Worker to perform client-side source code transformation for development purposes. We want to use Babel to transpile ES6+/ES2015 files to ES5 modules.
However, including the browser version of babel in a Service Worker using importScripts causes the following errors:
GET http://localhost:8080/babel-core/browser.js net::ERR_FAILED
Uncaught NetworkError: Failed to execute 'importScripts' on 'WorkerGlobalScope': The script at 'http://localhost:8080/babel-core/browser.js' failed to load.
So, the question is, how to correctly import babel into a Service Worker.
edit: This is not the obvious NetworkError, as we can change the content of the file into something simple, which enables us to actually load and execute the file. Also, the file can be loaded with a normal <script> tag.
edit2: To get this message, check out this repository https://github.com/onsetsu/lively4-core.git, start a local server at port 8080 and finally load http://localhost:8080/bootworker.html. We are currently using Chrome 44.
How about my experiment here https://github.com/bahmutov/babel-service - you can see the demo at https://babel-service-demo.herokuapp.com/.
I am using feature tests to detect supported features and transpile the intercepted code selectively. Of course this is just a start and only maps default parameters to babel plugins, but more features could be mapped.
Also, the people behind feature tests are discussing the selective transpile https://github.com/getify/es-feature-tests/issues/9
As a general rule, using a service worker for something crucial for a site's functionality isn't a recommended practice. Service workers are intended to be a progressive enhancement, and your sites should be designed to still be functional if the associated service worker isn't available.
Even in browsers which support service workers, there might not be one controlling your page if a user shift-reloads or if it's the very first navigation, before the service worker has had a chance to take control.
To answer your specific question, the ServiceWorkerGlobalScope under which service worker code executes exposes different functionality vs. a normal page's global scope, and it would appear that something in the browser.js script you're trying to import assumes functionality that's only available in a normal page. Unfortunately, Chrome's DevTools, even with the debugger enabled, doesn't reveal which specific statement is causing the error, so I can't say which exact statement(s) are invalid.
Chrome had introduced the use of extensions for WebRTC Screen Sharing. In this, each domain has to have the extension so that people install the extension in order to share the screen using webrtc.
Here is my use case:
During an on-going webrtc video call, if one person needs to do screen sharing and doesn't have the extension then after installing the extension one is required to refresh the page. This interrupts the call and both people need to join the call again.
I want to control the user experience using javascript so that refresh is not required. But if we don't do refresh, html page doesn't recognize the recently installed extension.
I have seen many open source code regarding this but none of them has use case similar to mine. They assume the extension to be installed during the session.
However, I had seen www.uberconference.com and they have similar use case. I tried installing the screen sharing extension during a live call and it did not require the page refresh and did not interrupt the call. It did the screen sharing right after extension was installed.
I could not understand how they did it as uber is not open source. Many people say that refresh is must after installing the extension. Any help in this case will be highly appreciated.
Here is how I install the chrome extension using in-line installation:
$scope.installExtension= function(){
!!navigator.webkitGetUserMedia
&& !!window.chrome
&& !!chrome.webstore
&& !!chrome.webstore.install &&
chrome.webstore.install('https://chrome.google.com/webstore/detail/<some-id>',
successInstallCallback,
failureInstallCallback
);
};
function successInstallCallback() {
//location.reload();
}
function failureInstallCallback(error) {
alert(error);
}
This is something we recently changed in getScreenMedia. View the pull request to see how we did it:
I wrote about the changes on my blog, so look there for more details, but the important bits are:
Instead of creating a communication channel on chrome.runtime.connect, and messaging directly, we can use external messaging. Instead of posting a message to the window, which gets picked up by the content script and passed to the background script (and vice versa), we can use chrome.runtime.sendMessage(extensionId, options, callback) and, in the background script chrome.runtime.onMessageExternal. This works where the other solution doesn't, because background scripts are loaded immediately upon extension installation, whereas content scripts are injected on page load.
So, basically, the extension uses a different permission:
"externally_connectable": {
"matches": [
"https://example.com/*"
]
}
And a different API:
chrome.runtime.sendMessage combined with chrome.runtime.onMessageExternal
instead of
window.postMessage combined with window.addEventListener('message') and chrome.runtime.connect.
At least two different sites https://apps.mypurecloud.com and https://beta.talky.io do screen sharing with inline extension installation with no reload at all.
This may helps today. If you are running Janus demos on the localhost - just run it over https.
If you will run it over http : the getDisplayMedia function will not be declared (e.g. in Chrome), and then Janus will ask you for plugin install.
If you had installed your own Janus-server: to use https - you must to configure ssl-certificates in Janus server configs:
janus.transport.http.jcfg - if you're using https in server definition
janus.transport.websockets.jcfg - if you're using wss (and don't forget to enable secure web-socket in it)
Have you looked at Chrome Extension Inline Installation ...
https://developer.chrome.com/webstore/inline_installation
I was having the same problems until I put within the html <head> tag ...
<link rel="chrome-webstore-item" href="https://chrome.google.com/webstore/detail/[your-chrome-extension-id]" >
Your extension manifest also needs to include the domain that this head tag is on.
Is there a way to check file size on the client (without the use of ActievX which also errors out), before it is passed back to the server? in asp
In ASP? No, by definition. Active Server Pages can't do anything before they get a request from the client.
There is a draft File API that will allow you to perform this sort of check using client side JavaScript. The Mozilla Developer Network has a guide on getting information about selected files. Once you have a reference to the file, you can just access its .size property.
Note that since the specification is a draft, it is rather new and subject to change. This one is very new and thus has [very limited browser support](http://caniuse.com/#search=file api).
You might also be able to achieve what you want using a Java applet or Flash (the latter of which would be better supported).
I'm trying to use the new chrome inline install feature for extensions (see here: http://code.google.com/chrome/webstore/docs/inline_installation.html).
I can't get it to work unfortunately, and have very little clues to go by. I've added the link element to the head element
<link rel="chrome-webstore-item" href="https://chrome.google.com/webstore/detail/pnnfemgpilpdaojpnkjdgfgbnnjojfik">
and I call
chrome.webstore.install();
in a jquery event handler. I've also verified my domain, however, I'm testing this on a local machine but have a subdomain pointed to my localhost (i.e. testing on dev.getbentobox.com which is mapped to localhost in my hosts file if that makes a difference).
When stepping through my js using the chrome debugger, chrome.webstore.install() is getting called and the function is defined. However, nothing happens - no install, no javascript exception, no console printing, nothing.
any ideas?
Your Chrome Web Store item doesn't show the verified site. If you compare it to the "We Heart It" extension, which can be inline installed from http://weheartit.com/heart-button, it has a green check saying "from weheartit.com". You'll need to edit your Web Store item, and associate your verified site with the item.
As of December 2018 (Chrome version 71), Google has disabled this feature. The workaround is to send the user to your extension in the Chrome Web Store.
Source: https://developer.chrome.com/extensions/inline_faq#change_dec18
What will change in M71 (Dec 2018)?
Beginning in M71, Chrome will no longer support the chrome.webstore.install() method and calling it will fail, resulting in a broken installation flow on your site. At this point calls to the API will throw a JavaScript TypeError. You should remove any calls to the API method before this date.
I want temporarily disable websocket in Google Chrome to debug a javascript to make sure it work for any browser without websocket support.
To begin, I'd say that there are better mechanisms to test your JavaScript in a websocketless environment. You could run your JavaScript in IE9, for instance, which doesn't implement the protocol. They're still disabled for the moment in Firefox 4 as well, if that's more your style.
Assuming that there's some good reason that you need to test in a websocketless Chromium, I think you're out of luck. There's not a trivial mechanism to disable WebSockets in Chromium. It's not built in as a command-line switch, nor is there a configurable flag. Since there's no mechanism to make this happen natively, I wouldn't suggest spending time testing the scenario. Every version of Chromium that your users use (e.g. 9+) has websockets enabled.
All that said, if you really need to disable websockets, the closest you can get without recompiling the browser would be to drop the relevant variables in your test code:
WebSocket = undefined;
would be relatively brute force, but should work. You could even create an extension to inject that JavaScript into every page you visit, for a truly websocketless experience (assuming, again, that that's somehow valuable for your use case).
I was able to block WebSockets with Fiddler.
Go to Rules / Customize Rules... in the Fiddler menu
Add this code to class Handlers (I put it after the existing RulesOption items):
// Block Websockets
public static RulesOption("Block Websockets")
BindPref("fiddlerscript.rules.BlockWebsockets")
var m_BlockWebsockets: boolean = false;
Add this code in OnBeforeRequest:
if (m_BlockWebsockets && oSession.oRequest.headers.Exists("Connection") && oSession.oRequest["Connection"] == "Upgrade") {
oSession.oRequest.FailSession(502, "Blocked", "Fiddler blocked websocket connection");
return;
}
This adds a menu option Block Websockets to the Rules menu. When it is toggled on, ws connections should be blocked based on the Connection: Upgrade header.
After seeing #user3661841's answer on another question, I created a GreaseMonkey/TamperMonkey script that will allow you to disable WebSockets in a similar way.
Here's instructions for Chromium based browsers (Chrome, Brave, Sidekick, etc.):
Download the TamperMonkey extension from the Chrome Store
Install this script from GreasyFork. By default, installing this script will disable WebSockets on every site you visit. If you don't want to block WebSockets immediately, click on the TamperMonkey icon and the toggle switch to disable blocking.
When you want to turn off WebSockets, click on the TamperMonkey icon and the toggle switch to enable blocking. Refresh the page.
Disable the script when you no longer want to block WebSockets.
Here's the switch you want to click to disable/enable WebSocket blocking:
NOTE 1: You should be able to see output in your console marking that the WebSocket connection was attempted to be opened, but blocked.
NOTE 2: Make sure to disable this when you're done disabling WebSockets for development. If you only use TamperMonkey to disable WebSockets, You'll want your TamperMonkey to look like this most of the time:
And like this when you want to block:
To disable ws you can simply add "Request blocking" in chrome dev tools, but only if specific file is initiating websocket to prevent it from loading if you can't do that this solution might not work
For example:
https://www.websocket.org/echo.html
Websocket connection is initiated by echo.js, so you can prevent that file from laoding and websocket will never start.
Initiator file can be found in network tab