RSS feed not working since this morning

Bug reports and enhancement requests
skriptimaahinen
Senior Member
Posts: 213
Joined: Wed Jan 10, 2018 7:37 am

Re: RSS feed not working since this morning

Post by skriptimaahinen » 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?
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0

mkz
Posts: 6
Joined: Mon Oct 23, 2017 3:22 pm

Re: RSS feed not working since this morning

Post by mkz » 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.
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

User avatar
Giorgio Maone
Site Admin
Posts: 8955
Joined: Wed Mar 18, 2009 11:22 pm
Location: Palermo - Italy
Contact:

Re: RSS feed not working since this morning

Post by Giorgio Maone » 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.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0

Post Reply