InformAction Forums

Posted: **Sun Mar 18, 2018 1:58 pm**

browser.contentScripts method seems to work fine, though apparently contentScripts.register doesn't understand urls with port numbers, so for the urls like http://localhost:8000 or http://127.0.0.1:8000, the contentscripts are not executed.

This is however easily fixed with for example:

Code: Select all

let a = document.createElement("a");
a.href = url;
a.port = ""
url = a.href;

in the executeOnStart and the contentscripts are loaded regardless of the port.

However, in case the browser.contentScripts is not available, the webglblocking becomes utterly unreliable, the result changing almost every reload. That does not surprise me though. I did some testing using browser.tabs.executeScript in onHeadersReceived, but could not make it work either, excluding the filter.ondata method that seems reliable. Can't figure why though.

Also, if I may ask, what is the purpose of returning object from the getContext rather than null?

Posted: **Mon Mar 19, 2018 10:10 am**

10.1.7.4rc1 works fine for me now, thank you. I don't know why WebGL is disabled for my trusted sites - it must have been something I did by accident when I was trying to work out how to use the new interface last year.

Posted: **Mon Mar 19, 2018 10:47 am**

skriptimaahinen wrote:browser.contentScripts method seems to work fine, though apparently contentScripts.register doesn't understand urls with port numbers, so for the urls like http://localhost:8000 or http://127.0.0.1:8000, the contentscripts are not executed.

Nice catch, thanks!

skriptimaahinen wrote: This is however easily fixed with for example:
Code: Select all
let a = document.createElement("a");

No need to use the DOM for that, fortunately:

Code: Select all

let u = new URL(theURL);
if (u.port) {
  u.port = "";
  theURL = u.toString();
}

skriptimaahinen wrote: However, in case the browser.contentScripts is not available, the webglblocking becomes utterly unreliable, the result changing almost every reload. That does not surprise me though. I did some testing using browser.tabs.executeScript in onHeadersReceived, but could not make it work either, excluding the filter.ondata method that seems reliable. Can't figure why though.

Fortunately, browser.contentScript is available on any Firefox Quantum we care for (59 and above), and filter.ondata was a Firefox-specific WebExtensions API anyway. BTW, I think I should file a bug report about webRequest.filterResponseData breaking feeds and possibly other stuff...

skriptimaahinen wrote: Also, if I may ask, what is the purpose of returning object from the getContext rather than null?

It makes position-precise placeholders available in more situations, by making the caller less likely to fail before putting the canvas element into the DOM.
Look at the difference at https://get.webgl.org, for instance.

InformAction Forums

RSS feed not working since this morning

Re: RSS feed not working since this morning

Re: RSS feed not working since this morning

Re: RSS feed not working since this morning