News for hackers. Stuff that matters.
Re:The Future of Developing Firefox Add-ons by tetraodonpuffer on Friday August 21, 2015 @10:48AM (#10097832)
I was under the impression that add-ons like ublock / umatrix were possible only in firefox due to its very permissive add-on model, if mozilla is going to deprecate XUL / XPCOM would it mean this kind of add-on won't be possible anymore?
Re:The Future of Developing Firefox Add-ons by takeda on Friday August 21, 2015 @11:28AM (#10098118)
I think those will work fine, my worry is that significant part of extensions that I use will no longer be available. I don't believe their functionality can be replaced with web extensions.

Here are some: - FireGestures (mouse gestures) - NoScript (it can do much more than the Chrome equivalent) - SecureLogin (wand-like behavior from Opera; basically instead filling login and password after page loads it logs you in after pressing a button) - Tab Scope (thumbnail of webpage when you hover over a tab) - Tree Style Tabs (it does what the name says) - Informational Tab (this I can live without, but I like it, it puts progress bar in the tab which looks nice)

This news sucks, first Opera 12 was discontinued and replaced with Chrome with different skin. I finally moved to FF and used multiple extensions to get some of Opera functionality back and now those are going away.

Re:The Future of Developing Firefox Add-ons by timdafweak on Friday August 21, 2015 @10:55AM (#10097896)
That's the first thought that came to my mind as well.

Addons like Fire Gestures and Easy Dragtogo are what keep me on Firefox. Chrome can't implement those apparently, and now it seems that support for them will be deprecated too.

Re:The Future of Developing Firefox Add-ons by snowwolf on Friday August 21, 2015 @10:50AM (#10097847)
Re:The Future of Developing Firefox Add-ons by tetraodonpuffer on Friday August 21, 2015 @10:53AM (#10097873)
thanks for the clarification, I haven't looked at add-ons for other browsers for quite a while, and at the time I remember discussions about adblock not being possible to be done anywhere else like in FF due to the add-on model, glad to see this does not seem to be the case anymore
Re:The Future of Developing Firefox Add-ons by the8472 on Friday August 21, 2015 @11:09AM (#10097987)
well, one could frame it differently

  - adblock pioneered on firefox
  - deemed useful
  - chrome implements necessary APIs
  - can finally be implemented on chrome too
For that to work you first need a permissive enviornment where the addon developers can think outside the box and do things not covered by the standard APIs.

Just like you can, as ultima ratio, write kernel modules if your system has no other way to support whatever you need to be do.

Re:The Future of Developing Firefox Add-ons by falcolas on Friday August 21, 2015 @11:02AM (#10097946)
I think the big difference is being able to pre-emptively block/modify requests, vs. changing what is displayed after the fact.
Re:The Future of Developing Firefox Add-ons by tetraodonpuffer on Friday August 21, 2015 @11:16AM (#10098047)
that was what I thought as well, however I went to the umatrix github page and if you look at the top it links this page[1] that discusses how umatrix needs permission to disable prefetching so no network connections are made for blocked sites, which seems to imply it can do the pre-emptive blocking as opposed to just hiding of elements.

I am wondering though now if I am mixing things up in my brain and the issues were with safari add-ons as opposed to chrome/chromium: there is no umatrix for safari[2] that I can see, ublock seems available but not ublock origin, but I am not sure if ublock on safari just hides or actually pre-emptively blocks.

[1] https://github.com/gorhill/uMatrix/releases/tag/0.9.1.2

[2] https://github.com/gorhill/uMatrix/issues/96

Re:The Future of Developing Firefox Add-ons by gorhill on Friday August 21, 2015 @11:34AM (#10098165)
> umatrix needs permission to disable prefetching so no network connections are made for blocked sites

Disabling pre-fetching is to prevent a TCP connection to be established at all, and this is something that needs to be also dealt with in Firefox -- it's not just a Chromium thing. This ensures that no TCP connection is established before it has been decided whether a network request must be blocked or not.

Chromium used to not be able to support the pre-emptive blocking of network requests, but that has been remediated in 2012 with its webRequest API in Chrome 17.

[1] https://developer.chrome.com/extensions/webRequest

Re:The Future of Developing Firefox Add-ons by the8472 on Friday August 21, 2015 @11:50AM (#10098280)
Which brings us back to the point that one cannot develop any new, unforseen kind of extension unless you either have the option to directly interface with the browser's internals or somehow get that API included in the browser.
Re:The Future of Developing Firefox Add-ons by tetraodonpuffer on Friday August 21, 2015 @11:49AM (#10098269)
thanks for clarifying and thanks a lot for continuing to work on your great add-ons!