
WebExtensions in Firefox 45 - e15ctr0n
https://blog.mozilla.org/addons/2015/12/21/webextensions-in-firefox-45-2/
======
dang
We've closed this thread to new accounts because of trolls.

If you have a new account and want to comment here, you're welcome to email us
at hn@ycombinator.com.

------
xg15
I understand (and applaud) the mission to make a cross-browser compatible,
predictable format for extensions. What I don't understand is why Firefox is
apparently introducing some of Chrome's more weird limitations with it as
well:

E.g., XUL add-ons were free to add as many toolbar buttons and menu items as
necessary; WebExtensions are restricted to a single button.

Likewise, Firefox had a well-functioning way for extensions to access page JS.
This is now replaced by Chrome's awkward approach of injecting script
elements, sending messages and praying that no collisions occur.

Why that?

~~~
mook
I believe the injecting script part is to support having the chrome and the
content in different processes.

I'm sad that, on the UI modification front, the new system doesn't seem nearly
as powerful as XUL overlays. I worry that when Servo comes into production
use, all that extensibility will be dropped (with Chrome not having it as the
justification) and we'll be left without a highly customizable mainstream
browser.

------
oblio
Does anyone know if more complex extensions such as Tab Mix Plus or Tree Style
Tabs will be supported?

~~~
wittekm
They want to add hooks for it, noting Opera already has a sidebar API.
[https://wiki.mozilla.org/WebExtensions/Future](https://wiki.mozilla.org/WebExtensions/Future)

I've seen similar sentiments echoed by Mozilla devs in a reddit AMA a few
weeks ago.

~~~
kuschku
Sadly, they won’t add nearly enough APIs, they already announced that most of
the UI won’t be customizable.

I’d have preferred a full UI customization like in Vivaldi.

~~~
mmebane
That's disappointing. Do you have a reference for this? I'm curious if there
were any details in the announcement.

------
pcx
This is great news! Especially the part where Web Extensions are going work in
Chrome without any changes!

~~~
TazeTSchnitzel
With minimal changes, I think. IIRC Firefox has a slightly different packaging
format.

------
uxcn
I understand, and even agree with, a lot of the goals behind the WebExtensions
API. I'm honestly still worried firefox isn't going to encourage plugins like
pterosaur, pentadactyl, etc.. going forward.

Will modifying the UI and the DOM essentially be verboten?

~~~
Certhas
I think Mozilla is highly aware of the importance of the extension ecosystem.
They don't want to alienate people

[https://billmccloskey.wordpress.com/2015/08/21/firefox-
add-o...](https://billmccloskey.wordpress.com/2015/08/21/firefox-add-on-
changes/)

[https://wiki.mozilla.org/WebExtensions/FAQ#Which_add-
ons_wil...](https://wiki.mozilla.org/WebExtensions/FAQ#Which_add-
ons_will_stop_working_when_XUL.2FXPCOM_is_deprecated.3F)

There are also proposals for ensuring that innovation can still be driven by
extension developers:

[https://discourse.mozilla-community.org/t/proposal-native-
js...](https://discourse.mozilla-community.org/t/proposal-native-js-to-
embrace-extend-the-webextensions-api/3457)

~~~
uxcn
Native.js is interesting. I would wonder how it plans to handle things like
callbacks for various events though. As an example, a keypress in a textbox
(e.g. pterosaur). I haven't looked at the WebExtensions API in detail yet, so
it may already be a solved problem.

More specifically, editing text seems oddly neglected, which is disappointing
considering webmail, blogs, social media, stack overflow, etc... I'm glad
noscript is being given special consideration.

------
TazeTSchnitzel
Alongside the XUL migration, the move to requiring extension signatures has
provoked controversy.

I wonder, though. Since WebExtensions have fine-grained permissions, perhaps
you could permit unsigned extensions which don't do potentially nefarious
things?

------
protomyth
Is it possible to write a DownThemAll!-like extension?

I'm still a bit confused on why I should continue to use Firefox when all the
features of extensions are stripped to be compatible with Chrome. What am I
missing?

~~~
TazeTSchnitzel
Unless I'm missing something, you could probably write DownThemAll as a
bookmarklet. All it does is scan a page for links and download them.

~~~
protomyth
It does do a tad more than that as it has filters and works on links and
embedded images with pause and resume.

~~~
chii
Yep. Also the ability to rename the downloaded files according to a pattern.

------
rektide
This gives me so much hope that we might begin to grow better mobile user-
agents.

I know FF has had extensions ongoingly, but this really feels like it can
challenge mobile Chrome's unmoving rejection of extensions.

------
farresito
Not too relevant, but Firefox has gotten significantly slower in my computer
in the past few versions, to the point that I will most likely switch to
Chrome again. I barely have any extensions and it's never been slower than
what I have now.

~~~
tshannon
I've felt the same, especially with the developer tools, but I started using
Firefox developer edition, and it seems much, much faster, so I'm sure
improvements are coming.

~~~
farresito
Thank you for the tip. I installed it and it does indeed seem faster. I
suppose the plugin compatibility is not too bad. EDIT: Seemms like my lovely
vimperator doesn't work too well.

------
bsimpson
So WebExtensions is Mozilla's name for a subset of the Chrome Extension API
they'll be implementing?

It's really weird to see a project named WebThing that doesn't seem to exist
outside of a particular vendor's blog/wiki. I'd expect to find a public
mailing list/GitHub repo/landing page without much searching. They don't even
own webextensions.org.

------
Eleutheria
Please, for all that is sacred, keep collaborating in an unified standard for
all major browsers.

As a developer who has to build extensions for all major browsers I'd
appreciate the effort.

------
MozillaEx
I worked closely with Mozilla during the first few years of Firefox.

It's only the same in name and logo these days.

The hard truth is internal and external politics in the organization were so
toxic senior-level programmers who were more risk averse were pushed out.

Imagine taking C++ pros who advised in the creation of W3C/IEEE/etc drafts,
and tossing them out in favor of node.js programmers.

The gray hairs were betrayed in favor of node hipsters. Whatever happened to
respecting those _who made you_.

This hits hard. The truth is Mozilla's days of glory are numbered.

Over the coming years the decline will come to eventually wrestle Firefox out
of Mozilla's hands and into a normal open source project.

Was all this office backstabbing worth it?

This is what happens when you lose the hacker ethic. It's disappointing.

~~~
ihsw
That was over a decade ago, things change.

Firefox is more relevant now than it was before, I welcome their efforts to
change with the times.

They are taking massive risks now, simultaneously developing an entirely new
programming language (Rust) and building an entirely new browser engine on it
(Servo) is ambitious. It is clearly self-evident that it has paid off.

There is nothing wrong with node.js programmers, your implication that they're
inferior is a broad-sweeping and baseless generalization.

The grey hairs are most certainly still around, and they're most definitely
well-respected. Rust's C++ roots is evidence of this.

Mozilla is flourishing, that cannot be denied.

Firefox is a normal open source project, Mozilla receive's contributions from
around the globe.

The hacker ethic isn't gone, it matured into something better.

[https://github.com/mozilla/](https://github.com/mozilla/)

~~~
Scarbutt
Real question, how is Mozilla flourishing when its main product, Firefox, has
been declining in market share for years?

~~~
scriptproof
\- Thunderbird: Dropped.

\- FirefoxOS : Dropped.

\- Servo: How many years do they need to build a new browser with the
experience they already have?

\- Rust: I don't expect the world to rush to this language.

\- Finally, Mozilla is just Firefox now and they are aimed to privacy at all
cost, that will cut their sources of revenues, of course.

~~~
pcwalton
Servo is not a new browser.

And nobody has "rushed" to any language introduced in the last decade. The
"conquer the world" mentality introduced by Java is over. The big programming
language success stories—Scala, node.js, Go, etc.—have all flourished with
devoted communities using the languages in the niches they're strongest in.
That's what Rust is aiming for, and the resulting community has been amazing
so far.

~~~
Touche
Hi pcwalton, I just wish Servo had clearer goals. In some ways the recent
faster-browser initiates have all come out empty in my opinion, as they have
nothing to truly show the for the work.

Flexbox is a great example. We were told the problems with DOM updates was
caused by the old layouts and things like floats. So Flexbox was supposed to
fix those problems. Where's the proof?

I find myself frustrated that now 8 years after the iPhone the web is still
incapable of so many things. I wish the browser community would make some
_very specific_ goals and say "we'll do whatever it takes to reach these".

Here's a very simple goal: A swipeable sidebar. Here's the requirements:

* It must retain 60fps no matter how fast you swipe.

* It must be easy to create; a virtual-dom shouldn't be a requirement to make up for slow dom updates. A elaborate library that correctly times everything shouldn't be necessary.

That's it. Make that happen. Do whatever it takes. Create another new layout
if necessary. Create a new touch spec that's faster, if necessary. Whatever.
it. takes. And then when the work is done you can point to this new widget and
say that the initiative paid off.

~~~
pcwalton
> Hi pcwalton, I just wish Servo had clearer goals.

What is not clear about "parallelize all parts of the pipeline", "get
rendering GPU bound", and "write a memory safe browser"?

> Flexbox is a great example. We were told the problems with DOM updates was
> caused by the old layouts and things like floats.

Nobody said that.

> So Flexbox was supposed to fix those problems.

No, it wasn't.

> I find myself frustrated that now 8 years after the iPhone the web is still
> incapable of so many things.

Me too.

> Here's a very simple goal: A swipeable sidebar.

You can do it already at 60 FPS. Make an overflow:scroll div and allow the
user to scroll it into view. Or even just do it manually with the DOM. It will
easily be 60 FPS in existing engines _if you animate transforms_.

> That's it. Make that happen. Do whatever it takes. Create another new layout
> if necessary. Create a new touch spec that's faster, if necessary. Whatever.
> it. takes. And then when the work is done you can point to this new widget
> and say that the initiative paid off.

There's nothing to do here, as you've described it.

But your comment is actually illustrative of the real problem (at least, what
I think it is). We have a ton of ways to do things on the Web. Some of them
are fast, and some of them are not. Web developers don't realize what the fast
paths are (which is not entirely their fault). I think that all of the paths
should be fast, and I think that many of Servo's technologies (such as
WebRender) go a long way toward making that happen.

What's frustrating is comments like yours that describe things that the Web
can clearly already do and blame browsers for supposedly being unable to do
simple things. I used to think the way you did—that the Web is incapable of
rendering a 60 FPS scrollable view—and then quickly discovered that, if
optimized properly, there is actually no problem. What I think the problem
with Web slowness is that Web authors don't know what the fast paths are, and
they use things like jQuery.animate() that hit all the slow paths. That is a
problem that I think we are well equipped to solve in Servo due to things like
parallel style recalculation, off main thread layout, and WebRender, but it's
a lot more nuanced than what you describe.

~~~
Touche
> What's frustrating is comments like yours that describe things that the Web
> can clearly already do and blame browsers for supposedly being unable to do
> simple things. I used to think the way you did—that the Web is incapable of
> rendering a 60 FPS scrollable view—and then quickly discovered that, if
> optimized properly, there is actually no problem.

I think you misunderstood the widget I'm describing. It is _swipeable_ meaning
I swipe to pull the sidebar into view and swipe to push it out of view. If I
stop half way the sidebar stops where my finger stops.

Meaning the sidebar has to follow my finger, at 60fps, as I quickly swipe in
and out. If such a thing is as easy you claim then a quick demo should be easy
enough. I know of no such sidebars on the web that fit this requirement, but
am happy to hear all of those devs (and myself!) are just terrible at their
(my) jobs.

~~~
lhecker
Does this suffice? [http://www.jqueryscript.net/demo/Responsive-Fluid-Sidebar-
Pl...](http://www.jqueryscript.net/demo/Responsive-Fluid-Sidebar-Plugin-with-
jQuery-Hammer-js/)

You need to use a Smartphone for the Demo above though (i.e. sth. that can
produces touches and has a small enough screen), but it was the first thing I
found by googling "hammerjs sidebar".

I'm sure that if you look at a few demos from hammer.js (which is a very -
maybe the most - popular touch library) you'll understand why everything you
always wanted has already been solved years ago - just not in a very easy way.

But it seems that didn't stop the world from writing libraries that make
swiping, panning, and fluid 60fps easy to achieve. Just like with any other
language, framework, etc. you just need to learn it well enough...

~~~
xg15
> Does this suffice?

The example is broken in Chrome 47 on Android 6.0.1: Once I touch the menu
putton, the sidebar immediately extends fully. Then i need to swipe right-to-
left multiple times to retract it again.

------
ck2
Still stuck on 41.0.2

Guess they are never going to fix gdocument.

And then there is the matter of allowing private/local extensions.

Might have to take another look at Pale Moon or Waterfox

~~~
michaelmrose
"What makes Waterfox so fast? It's built with Intel's C++ compiler. One of the
most powerful compilers out there. This enables us to make the fastest
possible web browser for all the code changes we make. This potent combination
makes for an unparalleled browsing experience."

So basically a build of firefox with a different compiler with binaries
available for only mac and windows.

For extra fun its based on an older version of firefox and there is no reason
to believe it has devs backporting fixes from higher versions nor that there
is anybody with the chops to build anything useful on top of it meaning it

\- Is virtually guaranteed to have security vulnerabilities and bugs that have
already been fixed elsewhere

\- It will either end up with the same flaws you don't like about firefox or
alternatively it will be forever stuck at an old version while the bad guys
find more and more exploits.

