Which is weird because FF devs are active in spec discussion for web components. Maybe they are working on some lower-level infrastructure stuff before they can tackle these, I'm not sure.
Firefox already has most of the pieces for web components because XBL (an XML thingy for building UI widgets that is basically WebComponents but older). I suspect it's just blocked on deciding when the spec is ready for implementation in Firefox.
So, when will we be able to use WebExtensions to modify the main UI’s scripts and DOM?
I want to add tab previews with screenshots on hover (as in vivaldi), I want to use custom history (and completely change the way the omnibar works by searching through that custom history server with fulltext indexing of all visited webpages).
When can we expect that (which is possible with existing extensions) to land in WebExtensions?
Not any time soon. They're aiming for maximum compatibility with Chrome extensions, and Chrome doesn't have anything like that, so I wouldn't expect it to be a priority in Firefox either.
The new multi-process architecture is fundamentally incompatible with many of their old extension APIs. The new multi-process architecture is one of their priorities (they're the last popular browser to get a multi-process architecture -- even IE has had this forever -- and it will solve many of their performance issues), and so another priority is implementing new APIs for extensions to use.
I seem to remember them saying that they're interested in adding functionality required by the current addons though. Probably less of a priority than perfect compatibility with Chrome though.
IIRC they're also aiming for most existing extensions to still work (and working with extension authors on this). The extensions will require updating, but the base functionality won't be lost from the spin so an extension that used to work can be rewritten to still work.
The Chrome API is just a base. There's a lot of misinformation about this switch floating around. The intention is to not break existing addons.
They have compatibility layers available. You don't have to wait for WebExtensions to add those features, just do it with the old APIs and switch when ready.
I assumed that the GP meant a permissions system for users, not for WebExtension developers. I don't believe there is that. It seems like it would be relatively trivial to add given the manifest permissions system is already in place though.
Actually for certain classes of iOS 'apps' you can do exactly this - to enable third party iOS keyboard access you need to go into Settings and enable an extended privilege set (which includes internet access)
As well as Android and iPhone, many auth services (e.g. Facebook Connect) also offer this feature to presumably mostly non-technical users.
Also, I've not investigated but I doubt the WebExtensions API would provide access to features required to implement this as an extension (it's a much more limited extension API than previous Firefox ones)
Firefox should concentrate on its biggest asset, ability to customize natively. For example I would like option to customize right click so when i right click term i would like to have ability to search by all search engines that i want to use not only default.Also most annoying thing in both browsers is not having ability to copy link as text not only its address.
It makes extra sense to have it on touch-only platforms, where selecting text is more difficult (and long-pressing a link doesn't initiate text selection).
On a mid-2014 Macbook Pro, I'm having a hard time right-clicking without selecting the text using the touchpad. I think its automatic. How are you doing it?
I am using right click with a magic mouse on an early 2011-mbp. FWIW I just tried it on my touchpad without selecting anything and it doesn't show that copy option in the context menu. It is possible that it's a setting somewhere.
Context Search is actually worse than default because i don't want to add one more click to access default search engine search i want to stay as it is and below that add wikipedia and WolphramAlpha engines.
Agreed. Firefox has two advantages: it's customizable, and it's not made by a major tech company. If the customization goes, then there's only one advantage left.
It's a good reason IMO. MS browsers push MS services and Google does the same with Chrome. For example, I have to be logged in with my G account to download an extension for my browser. I am struggling to see the connection between the two.
Finally, google links everything together (as we saw with the resold Pixel debacle), so why would I want to increase the risk of breaking Google TOS by using their browser.
Firefox pushes Mozilla services, such as their "Sync". They've also pushed commercial services, such as "Pocket", over user objections.[1] And, of course, they were paid to make Yahoo (of all things) the default search engine.
They don't really push Sync. Most people are unaware of it.
I disagree with many of the concerns over Pocket as they are alarmist and overblown. The Pocket code is MPLv2 (open-source) and it isn't "spyware". This is trivially verified by looking at the code.
Mozilla used to have a partnership with Google that accounted for 85% to 91% of their revenue. Mozilla needs funding to survive, and Yahoo! provides some of that funding.
It is a false equivalence to suggest that the way Microsoft or Google pushes their services is anything like Mozilla's actions. Mozilla has always pushed for an open web and strong privacy protections. Google only implemented Do Not Track after Firefox did. Mozilla just released an ad-blocking browser for iOS to go along with their ad-blocking add-on. Comments like these only push that false equivalence.
Mozilla's Firefox Sync server code is open source and even packaged so you can run your own Firefox Sync server, if you are concerned about privacy or Mozilla no longer supporting the service:
Mozilla has been gradually restricting what add-ons can do in Firefox precisely because of problems with malware. This is another step in that process.
This is basically "we have to be compatible with the guys with the bigger market share". Unclear why. Nobody installs add-ons on Chrome. I have the same add-on for Firefox and Chrome, and it has 100x the installs on Firefox that it does on Chrome.
The current Firefox extension platform is a mess. There are XUL add-ons, Jetpack add-ons, and SDK add-ons, nothing is fully compatible with E10s, and to say the security features are lacking would be an understatement.
The Chrome platform on the other hand was designed to be multi-process from the ground up, has some solid security research behind it (like actual academic studies), and generally just makes sense. The Chrome extension system (or something very similar to it) is also already supported in a bunch of other browsers, so why would Mozilla not use it in theirs?
uBlock Origin, as a random popular example, has 2,231,919 users on Firefox and 6,483,302 users on Chrome. So Chrome has almost 3x as many uBlock Origin installs, though Chrome has about 5x more users than Firefox. From this one data point, it would seem that people using Firefox use more extensions, which interesting.
Might be a bad example, as Mozilla is promoting uBlock Origin right on the first page in the Add-ons section. It takes just three clicks to go from a newly installed Firefox to having uBlock Origin installed.
Then again, though, they only just recently switched that over from previously promoting AdBlock Plus, so I don't know how much of an increase that has caused in that time.
They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread.
Google Chrome was built with multithreading in mind from the ground up (well, even multiple processes), and its extension API was designed around that architecture.
I think Mozilla made the right choice by picking and extending an existing API that has seen a lot of real world code written against it, rather than inventing a new, incompatible one.
They needed to revamp the plugin architecture in order to support multithreading. The current FF extension API relies on the fact that the browser UI and the Web content share the same OS thread.
No, it doesn't. The long-obsolete XUL API did, but the current Jetpack API does not. There's a per-addon task and a per-page task, which communicate via message passing.
It's a nice side-effect to be compatible with Chrome-extensions, so that even if Chrome continues eating up the browser marketshare that there will still be extensions available on Firefox, but the main-motivation was simply that Firefox needed a proper extension API and then why design an API from scratch, if there already is one that does everything you need.
Tree Style Tabs should continue to work. It's a very popular extension. Mozilla should probably include a disclaimer about Tree Style Tabs still working with any blog post about WebExtensions. :)
Mozilla is now beta testing a prototype of native Firefox vertical tabs, though it is not as advanced as Tree Style Tabs:
Vivaldi has a nice Tree tab style that I constantly use, it has become second nature - we're even looking at replicating it for our enrollment software, crazy enough.
71 comments
[ 3.3 ms ] story [ 98.5 ms ] threadhttps://bugzilla.mozilla.org/show_bug.cgi?id=889230
https://bugzilla.mozilla.org/show_bug.cgi?id=1205323
Which is weird because FF devs are active in spec discussion for web components. Maybe they are working on some lower-level infrastructure stuff before they can tackle these, I'm not sure.
* https://blog.mozilla.org/addons/2016/08/02/multi-process-fir...
* https://developer.mozilla.org/Add-ons/Working_with_multiproc...
I want to add tab previews with screenshots on hover (as in vivaldi), I want to use custom history (and completely change the way the omnibar works by searching through that custom history server with fulltext indexing of all visited webpages).
When can we expect that (which is possible with existing extensions) to land in WebExtensions?
The Chrome API is just a base. There's a lot of misinformation about this switch floating around. The intention is to not break existing addons.
But if I'll implement these things, I'll want to do them using the new APIs in the first place.
So I'm waiting for the new APIs to come.
This seems far beyond the capabilities of most users to understand. Perhaps someone can make an add-on for power users who are interested.
Also, I've not investigated but I doubt the WebExtensions API would provide access to features required to implement this as an extension (it's a much more limited extension API than previous Firefox ones)
http://imgur.com/a/ncvyt
CoLT (Copy Link Text)
https://addons.mozilla.org/en-US/firefox/addon/colt/
You can customize it to copy in different syntaxes; for example you can have it copy in Wikimedia link syntax.
Finally, google links everything together (as we saw with the resold Pixel debacle), so why would I want to increase the risk of breaking Google TOS by using their browser.
[1] https://groups.google.com/forum/#!msg/mozilla.governance/2PY...
I disagree with many of the concerns over Pocket as they are alarmist and overblown. The Pocket code is MPLv2 (open-source) and it isn't "spyware". This is trivially verified by looking at the code.
Mozilla used to have a partnership with Google that accounted for 85% to 91% of their revenue. Mozilla needs funding to survive, and Yahoo! provides some of that funding.
It is a false equivalence to suggest that the way Microsoft or Google pushes their services is anything like Mozilla's actions. Mozilla has always pushed for an open web and strong privacy protections. Google only implemented Do Not Track after Firefox did. Mozilla just released an ad-blocking browser for iOS to go along with their ad-blocking add-on. Comments like these only push that false equivalence.
https://github.com/mozilla-services/syncserver
I dont think you deserve Downvotes because that's a perfectly reasonable point to discuss.
What? I can download chrome extensions just fine when logged out.
The response to the web of trust shit show should have been to neuter add ons.
The Chrome platform on the other hand was designed to be multi-process from the ground up, has some solid security research behind it (like actual academic studies), and generally just makes sense. The Chrome extension system (or something very similar to it) is also already supported in a bunch of other browsers, so why would Mozilla not use it in theirs?
E: typo
https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
https://chrome.google.com/webstore/detail/ublock-origin/cjpa...
Then again, though, they only just recently switched that over from previously promoting AdBlock Plus, so I don't know how much of an increase that has caused in that time.
Google Chrome was built with multithreading in mind from the ground up (well, even multiple processes), and its extension API was designed around that architecture.
I think Mozilla made the right choice by picking and extending an existing API that has seen a lot of real world code written against it, rather than inventing a new, incompatible one.
No, it doesn't. The long-obsolete XUL API did, but the current Jetpack API does not. There's a per-addon task and a per-page task, which communicate via message passing.
[1] https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_AP...
https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
The moment this plugin stops working is the moment I stop upgrading. Seriously!
Mozilla is now beta testing a prototype of native Firefox vertical tabs, though it is not as advanced as Tree Style Tabs:
https://testpilot.firefox.com/experiments/tab-center
https://bugzilla.mozilla.org/show_bug.cgi?id=1208596
and a larger in scope bug https://bugzilla.mozilla.org/show_bug.cgi?id=1315819