Hacker News Reader

Comment by wldcordeiro | Hacker News Reader

Most Firefox extensions are still in the older formats but it'd at least get a cross-browser extension system working.

Well, Firefox users would still have an advantage. That Chrome users will never get addons that add tree-style tabs, or completely modify the UI, etc, is obvious.

But from that point on Chrome does not have many things above Firefox anymore.

For users who primarily care about extensions, but that's been true for a while. I rarely use extensions (currently I'm using, uh, Google Cast, plus the mosh Chrome app because life's too short to install software) and I care about security, and Chrome's multiprocess and sandboxed architecture has significant wins there.

When Firefox gets that, then I'd agree that at least for me, Chrome won't have many things above Firefox any more. And the new extension system is part of their plan for getting there.

> Chrome's multiprocess and sandboxed architecture has significant wins there. When Firefox gets that,

Multiprocess is currently enabled by default on desktop in the Firefox developer edition. And the release version of Firefox on Android is multiprocess and also supports extensions.

In practice, about half the extensions I use (the complex ones, like Lazarus) need a serious overhaul to work with e10s. It can't hit a stable release, there would be major breakage.

There's a difference between chrome and ff multiprocess. The sandbox model (at least on linux) in chrome is better than anything else available right now. They're pretty much the reason that kernel-level sandbox is available to us now.

Hm, both viraptor and I were downvoted without significant commentary. While I don't mind downvotes for being wrong, is anyone interested in actually claiming that we're wrong? As far as I'm aware, viraptor is completely technically accurate: the Chrome team is the reason that Linux's seccomp mode 2 is so good today. (In 2010-11 I was working on a project that assumed that the seccomp mode 2 rumors were never going to amount to anything, which was the consensus of the time.)

Also while I'm here, a certain [dead]-and-proud account linked this bug which is somewhat relevant (but only somewhat, in my eyes): https://code.google.com/p/chromium/issues/detail?id=477424

I don’t know enough about the sandbox model to discuss it (and I know that Google tries to have an amazing sandbox model especially because they run their browser also as OS)

But the sidebar stuff just can’t compete with the whole browser UI being effectively an XML document in the hands of an extension.

There were lots of interesting extensions doing crazy stuff with the UI at the beginning. Then they got split into some specific types, like: icon/action, content processing, extra information (typically as a side/top/bottom bar). To the point that I can't even think of one that doesn't fit in those scenarios. The extension authors were invited to comment on what's needed from the extension API to support their use case.

So are you one of the extension authors, or users? What exactly do you want to change in the UI and did you raise an issue with google or mozilla?

I am kinda both? I don’t publish extensions, but I like to write some for myself.

One case is that I can turn on/off aero glass, or add it for everything, or I can add modify the way the toolbar is unified, or I can create multiple rows of tabs, or colored tab groups.

At every moment in the past years, I used at least one of them, usually multiple such changes.

Effectively, what I want, is to be able to modify the browser UI the same way as normal XML documents. If mozilla now uses XUL, or if they use HTML, I don’t really care. What I care about is full customizability without having to recompile.

browser.html is one step in the right direction.

Reply on news.ycombinator.com