
Firefox.html: Rebuilding Firefox UI in HTML - ash
https://mail.mozilla.org/pipermail/firefox-dev/2014-December/002510.html
======
paulrouget
I've built that. Just to be clear: this is a personal project, not a mozilla
project (even though I'm a mozilla employee).

Also - many people find it silly to use HTML instead of the operating system
toolkit library. But it's not HTML _or_ native. It can be both. In this case,
the HTML code define the layout, and we can draw native widgets inside (look
at the <input type=submit> tag in HTML, it's a native widget). For example, if
you run the current build on Mac, you'll see that new tabs use Yosemite
"vibrancy" effect. Native look and native performance, can, in theory, be
achieved.

~~~
valarauca1
As a guy who works with primarily back end server code. I hate UI stuff
primarily because even creating small input UI windows requires jumping though
hoops of fire it feels like with strange API calls, and documentation that
says, "Just follow the example it'll all be fine in a couple minutes." But I'm
8 inheritance levels deep trying to figure out why my text box isn't
rendering.

I've often wondered why OS's just don't host browser render engines internally
and draw their UI with that.

Well I don't for long, I know HTML is much younger then X. Also browser
engines are massive resource hogs. But with the advent of 8-16+ GB of ram in
consumer computers can we really say 2-3GB for windows rendering is heavy?

Especially if it offers that much empowerment to developers.

~~~
rancur
no more software layers please! my PC was much faster when my programs were
native. Apps rendered with chrome rendered with webkit...8GB used to be
enough, then all these "developers" with their "development machines" who
think it's no big deal that their Hangouts implementation takes 200MB when
Pidgin takes 20.

people used to complain about Firefox hogging memory, I think it's Chrome we
should be worried about...

~~~
jwcooper
At the same time, it's likely much more expensive to code native apps than it
is to just build an html/css/js app using chrome with a lot of the heavy
lifting already done for you (at the expense of increased resource
consumption).

A lot of these apps wouldn't exist if they couldn't have been built quickly
and cheaply.

~~~
rancur
well, we're hitting process node limits (5, maybe 4nm) in 10 years so I think
we better stop it.

[http://www.chipworks.com/media/wpmu/uploads/blogs.dir/2/file...](http://www.chipworks.com/media/wpmu/uploads/blogs.dir/2/files/2012/04/FIN-410K-c_branded.png)

You see those little dots? Those are individual silicon atoms from one of a
few fins in the gate on Intel's 22nm node.

Also, I Am A C Programmer. I Think Everything Should Be Written In C. C Is
Close To The Hardware And Is Faster And Use Less Resource Compared To The
JavaSlow and WebKittenz and CSS. But I Like CSS Because It Has C In It. I Am A
C Programmer.

Get back to me when we have compressed ZRAM implementations and Same Page
Merging everywhere to save memory on each Chrome process and each JS
interpreter instance. Don't you want to do the green thing?

~~~
cptskippy
Congratulations, I thought I'd managed to go a whole year without hearing
about process limits and the grim future we face. Seriously, every 6 months or
so for the last 15 years or more there is an article published explaining the
end of the PC revolution. Google the terms "end of silicon" or "end of moore's
law" and add a custom date range like 1998-1999 and you'll get dozens if not
hundreds of articles from reputable sources saying that we've come to an
impasse or that in 3, 5 or 10 years we will be screwed.

When chips started hitting the limits of the photo-lithography process, they
switched to lasers, UV, DUV, and now EUV. Transistors start leaking so they
redesign them time and time again. We've gone from completely 2D Circuts to 2
layer 3D to what's it at now 16 layers? The end is nigh and has been since
Moore came up with that god damn law.

My point is that there's a lot a really brilliant people in the field who've
been working for years if not decades to address problems we haven't even had
yet. We're perpetually on the verge of a crisis, and simultaneously on the
verge of a solution to said crisis.

We're in an age of ridiculously powerful machines that we don't know what to
do with. If suddenly all progress halted in chip development and we had to
make due, we'd probably enter into an age of hyper optimization where software
engineers would be scrutinizing every clock cycle furthering the annual
performance gains we've had for the last 40+ years.

~~~
rancur
perhaps you didn't look at the atoms in the picture I linked.

At 4nm no amount of dielectric will save you from the quantum tunneling.

~~~
cptskippy
I'm not suggesting a solution, I'm simply stating that lots of brilliant
people have been aware of this eventuality and have been actively working on
next generation processes to address it.

~~~
rancur
if "next generation processes" is really the best you can come up with...

Those people are working on EUV at ASML. Those are the next generation
processes. What you're suggesting is they have some super science quantum-
tunneling barrier that the world has never heard of nor seen nor thought could
exist.

------
icefox
The browser shipped with Blackberry 10 was written in HTML and was a real joy
to develop.

Edit: some more public details

The default browser on the BlackBerry 10 platform was a completely new browser
application. The chrome was written in HTML, CSS and JavaScript. Being able to
develop the chrome on your desktop browser or being able to run inspector
remotely and using your desktop was very handy. The core was a command line
application called webplatform that "launched" a url that was a "webapp". The
webapp had API's exposed to it such as creating WebView's in or out of process
(yup blackberry has had multi-process tabs for a while now...). One joy was
being able to pull up the Javascript console for the browser WebView and
dynamically calling exposed c++ API's in any WebView in any process to test
out features or diagnose problems.

It started out as a quick little proof of concept I tossed together over a day
and the upside was large enough to invest time into. One of the reasons for
making the main browser in html was that as a platform we wanted web
application to succeed. Eating our own dogfood we made sure webapps could
handle the job. The API's that were needed were there, memory usage were low,
startup time was fast etc. And if you search for reviews of the blackberry 10
browser you will find that the end result was a success.

Edit 2: Much more in depth information can be found on this video which was a
presentation given at Blackberry Jam by several of my colleagues. Skip to the
23 minute mark to see some actual code of what a webapp browser would look
like.

[https://www.youtube.com/watch?v=bZ8vxhTezvs](https://www.youtube.com/watch?v=bZ8vxhTezvs)

~~~
soapdog
Congratulations on awesome tech. Can you confirm the browser still work like
this or did they change it to a non-HTML version in recent revisions?

~~~
icefox
I left RIM in 2012 so I could not confirm that this is how the browser works
in new devices released today. But given the success and advantages that
having the html browser gave us there would have to be some really compelling
reason (or $$$) to abandon it. The group I was part of was formally
TorchMobile and as a group had significant browser experience having written a
fair number so we understood the hassles of maintaining two projects. Being
able have webkit developers help with part of the browser made development go
faster on both sides (webkit devs could easily abuse the browser to test new
feature). Even if it isn't used in the browser as mentioned at the bbjam the
weblauncher application was used by not only the browser, but for a number of
other purposes.

I can only imagine there is a fair amount of overlap in Mozilla where there
are two developers working on the same thing, one for xul, one for html.

------
kibwen
I'm very excited at the potential of the browser chrome being implemented
entirely via standard web technologies. And given that Servo is never going to
implement XUL, it would save a lot of effort that would otherwise be spent
implementing a bespoke, minimally-functional UI (which has been tentatively
named Crow, if the MST3K reference wasn't already obvious).

See also this other thread linked from the discussion in the OP, "Moratorium
on new XUL features": [https://lists.mozilla.org/pipermail/dev-
platform/2014-Octobe...](https://lists.mozilla.org/pipermail/dev-
platform/2014-October/007160.html)

------
bkeroack
I realize this is a personal project, but this is deeply amusing considering
that:

1\. Way back when (circa 1998-2001?), the Mozilla project started as a radical
redesign of the next gen Netscape browser. One of the core principles of the
architecture was that the browser itself would render the UI elements (using
an HTML-like tech call XUL).

2\. The Firefox browser (then called "Phoenix") was a reaction against the
above, which was thought to make the browser too heavyweight and slow.
Originally Phoenix was the Gecko engine in a native UI window without all the
XUL overhead (and without all the other components of the Mozilla Suite like
the email client).

Now we're seeing the reverse trend, 15 odd years later.

EDIT: It turns out I misremembered about Phoenix dropping XUL completely--
rather they dropped XPFE for a "new light-weight XUL toolkit", along with
dropping all the non-browser components of the Mozilla suite.

~~~
Yoric
Well, XUL was quite ahead of its time. Most of XUL has now been incorporated
(and improved, and optimized) in HTML.

Also, Phoenix kept using XUL, just a rewrite that didn't attempt to do
everything from scratch, but relied upon native components wherever available.
Most of the Firefox UI is either XUL or HTML.

~~~
pimlottc
XUL also had my favorite namespace URI of all time:

[https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...](https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul)

------
taf2
This is great. My experience with XML for UI went something like this.

1\. build an XML language for abstracting C++ UI MCF or gtk

2\. realizing the need for HTML content - embed mozilla/xulrunner

3\. realzing xulrunner /mozilla already provide a cross platform toolkit use
XUL to build the user interface with xpcomm wrappers

4\. realize that HTML is better for user interface, and only write
HTML/javascript with xpcomm wrappers.

5\. switch to web development completely and avoid desktop apps all together
:)

6\. from time to time check in on the state of desktop/app development and see
if they've finally figured out html is better for interfaces than any
interface builder

~~~
adl
> from time to time check in on the state of desktop/app development and see
> if they've finally figured out html is better for interfaces than any
> interface builder

Is this for real? I can name numerous advantages of Web Apps have over
desktop/native Apps, "Building better interfaces" is not one of them.

Trying to build a UI with CSS and DOM manipulation (not to mention <div>
hacks, Bootstrap, Dojo/JQueryUI, different rendering engines, etc) is an
exercise in pain compared to basically _any_ modern UI toolkit. (From XAML to
Qt, Android, hell even GTK.)

edit: minor correction, I meant to say " build a UI" not "build a native UI"

~~~
STRML
You're right - but the real win here is that hundred of thousands of
developers already know HTML + CSS, and very few developers know XUL or even
any native UI API. Given that these native APIs change with the platform, many
developers have given up on them since HTML + CSS will be useful for the
foreseeable future.

Is XUL really better than HTML + CSS? Probably. But HTML + CSS is getting a
lot better (flexbox, etc), and tons of developers know it _now_ and can
contribute. Plus, dogfooding. I think it's a really good move!

Sure, RAM usage will probably get worse, but perhaps it will motivate them to
improve that as well, and all users of the browser on all pages will benefit
as a result.

~~~
adl
I don't know if XUL is better than HTML + CSS, I haven't used XUL. I have used
XAML and Qt, and the Android Layout Manager. and they are way easier to deal
with.

In HTML, a button is not a button, it's a DIV with an CSS properties (which
render differently depending on the browser) + some images + some Javascript.
And that abstraction leaks a lot.

The equivalent in native code will be having to deal with Xlib in X11 or GDI
on Windows every time you debug.

That said, there is value in HTML/CSS/JS UIs, I don't deny that, and I use
them when appropriately. I still think native UIs are 'cleaner' to develop.

~~~
STRML
While that's true, a lot of the frustration with HTML/CSS/JS melts away when
you have only a single target environment and don't have to worry about
browser compatibility. Targeting a modern environment like Gecko would
actually be quite nice; you could use a lot of modern ES6 features and
Flexbox.

------
Morgawr
Color me surprised, but when we get to the point where we run HTML to build a
browser that is supposed to be the tool used to render and display such
HTML... haven't we gone too far? Is a browser necessary? What is rendering
that HTML if not a browser?

I mean, I get it, a browser is used to browse (duh) the internet, not
necessarily to render HTML, but at this point we really need to ask ourselves
"why are we doing this, again?".

EDIT: Still impressive though, nice proof of concept!

EDIT 2: As much as I hate the "Why am I getting downvoted?" shenaningans that
people usually pull, I want to clarify the intent behind this post. I'm not
flaming or hating on the project, it's a cool idea. I was trying to spark some
insightful conversation on "where do we want to go from here?" and "do we
really need a browser if we have gone this far?". If you want to downvote me,
why not just reply to this post and have a nice interesting conversation
instead?

~~~
michielvoo
> What is rendering that HTML if not a browser?

The rendering engine (Gecko). I guess for it to make sense you must separate
the drawing engine from the browser, which adds things like tabs, bookmarks,
themes and add-ons.

~~~
kibwen
This can be seen today in Servo, which can browse the internet but has no GUI
of to speak of (e.g. to visit a URL you must pass it as a command-line
parameter to the executable).

------
matthewmacleod
This is a fantastic idea and I'm really glad to see experimentation in this
area. It's already great to look at how things like Webkit's dev tools are
implemented in HTML and see how that idea might be extended.

At it's core, a browser is an HTML/JS rendering engine with some chrome to
allow users to manage what pages they're looking at – and in most cases, that
chrome is actually pretty minimal. It seems like a natural evolution to play
with the idea of implementing that chrome in the natural UI language of the
browser engine too. Yeah, the tools aren't there yet – but experiments like
this will give us some scope to play around with what might be possible and
identify the pain points that must be overcome to make it a reality.

Great stuff.

------
nacs
Reminds me of Breach[1] / Thrust[2] which basically lets you do the UI plus
some low level stuff via Node/JS.

There is a 'browser in a gist' [3] using Breach which is a good example of its
use.

[1]: [http://breach.cc/](http://breach.cc/)

[2]: [https://github.com/breach/thrust](https://github.com/breach/thrust) (I
believe this is the new core of Breach by the same people)

[3]:
[https://gist.github.com/morganrallen/f07f59802884bcdcad4a](https://gist.github.com/morganrallen/f07f59802884bcdcad4a)

------
browserxul
Copy this into firefox's URL bar for a fun treat:

    
    
        chrome://browser/content/browser.xul

~~~
ehsanu1
Nice, and it nests too! Though with strange behavior after the first nesting.

------
agumonkey
I'm always pleased when I use chrome devtools on chrome devtools. So I can't
welcome this enough. Have fun.

~~~
kbrosnan
This has worked on Firefox since the beginning of time. One could use the DOM
inspector and venkman JS debugger, then Firebug chrome inspector and more
recently the Firefox developer tools to inspect Firefox's XUL.

[https://developer.mozilla.org/en-
US/docs/Tools/Tools_Toolbox...](https://developer.mozilla.org/en-
US/docs/Tools/Tools_Toolbox#Settings)

~~~
agumonkey
Ha, weird, I never felt the same direct access to the metalevel as in Chrome.
Just the other day I spend an afternoon trying to access Firefox restore
session url list through the developper tools without any luck, the XUL ~DOM
element was an opaque type I couldn't inspect.

------
espadrine
Can HTMLRunner be used as the basis of something like node-webkit[1]? What's
its strength / weaknesses compared to that?

[1]: [https://github.com/rogerwang/node-
webkit](https://github.com/rogerwang/node-webkit)

~~~
paulrouget
weaknesses: I built it in a couple of days. It's ugly. Designed for
Firefox.html only. Don't use it :)

~~~
voltagex_
How did you build it? I always thought the Firefox code was huge and
monolithic and couldn't be used like this.

~~~
espadrine
The main commit seems to be this: [https://github.com/paulrouget/gecko-
dev/commit/a3bb11e9bcf8c...](https://github.com/paulrouget/gecko-
dev/commit/a3bb11e9bcf8cf48184c522f9c1856d79db5025e)

You may notice a thin layer of XUL.

------
simonw
Would it be possible to implement XUL using Web Components and port the
existing XUL interface to HTML that way?

~~~
fnump
Possibly, yes. Though I would not recommend implementing it as is... XUL was
never versioned as far back as when I used to work with it, which is about 5
years ago. It's messy. Not easy to use. Although still easier than the new
flexbox standard that evolved from it.

Anyway I'd hope for something better than XUL/XBL. The potential was always
there. Mozilla the platform! —

I massage HTML and CSS professionally since 1996, and I must say I'd prefer
something like "XUL2" over my beloved web standards any day. I wouldn't mind
if "XUL2" was in actuality created with web components. Though seriously, CSS
and DOM (HTML/XML) were created to make you suffer. That's their true purpose.

There is no easy way out of this. And rewriting the web won't work either.

------
agumonkey
Live demo from github instructions :
[https://www.youtube.com/watch?v=pcCtRpkq53M](https://www.youtube.com/watch?v=pcCtRpkq53M)

ps: not my work, see :
[http://www.reddit.com/r/programming/comments/2ow1g0/firefoxh...](http://www.reddit.com/r/programming/comments/2ow1g0/firefoxhtml_rebuilding_firefox_ui_in_html_paul/cmr81pl)

------
misuba
Is there a connection between this and the old Chromeless project? (It doesn't
say there is, so I suppose my real question is, why not?)

~~~
Yoric
There have been many attempts at a chromeless app runner for Gecko, including
Prism and WebAppRT. If I recall correctly, Paul is using a variant of WebAppRT
as a runtime.

------
grumblestumble
I'm all for it if it means we finally get ::-webkit-scrollbar equivalency in
Firefox...

------
phkahler
What widgets are used? (I'm not a web dev and only dabbled in that over 15
years ago) If you use native widgets, then you end up with a cross-platform
app framework. If you create your own widgets, then you end up with a cross-
platform GUI toolkit and app framework. Which is it? Either way, this seems
quite interesting. OTOH, can you do apps this way with anything other than js?

------
hawski
This sounds like a good idea. But change should happen gradually - no to
parallel versions. Like author of zeroconf, when he was rewritting in in
OCaml: [http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-
ret...](http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-
retrospective/#porting-method)

------
1ris
Is this the first step to switch to servo?

~~~
Yoric
There are discussions on that topic. However, everybody needs to realize that
this is Paul's personal project, not an official Mozilla project, so don't get
your hopes too high.

That being said, I'm quite excited about that project, I opened a pull request
a few hours ago and it was accepted :)

~~~
kibwen
Can you link to the pull request? I'm curious to see it, but can't find it.

~~~
Yoric
[https://github.com/paulrouget/firefox.html/pull/17](https://github.com/paulrouget/firefox.html/pull/17)

------
shmerl
Interesting. But on Android Mozilla already deviated form this approach of
"webbiness" in favor of using native UI. Same as Sailfish browser does with Qt
and Gecko through IPCembedlite.

If not for that, Sailfish browser could reuse the UI.

~~~
minor_nitwit
Firefox OS on the otherhand is HTML.

~~~
shmerl
Yeah. So I wonder if Mozilla is going to switch to HTML UI on other mobile
platforms too.

------
blueskin_
>we could drop XUL and close the gap between B2G and Firefox Desktop

I hope not. Customisability is always the first thing to die in mobile 'apps'.
As soon as that happens on the desktop, I'm moving to Pale Moon permanently.

~~~
dschep
What about this (using HTML instead of XUL) would make it less customizable?
If anything, it's at least more accessibly customizable because more of us
know HTML than know XUL.

Also, I imagine if this truly the way forward, XUL will be removed from the FF
code base, thus making a XUL based Pale Moon trickier since it would be so
different from upstream at that point.

------
gesman
I wonder if this could be used to visually replay captured HTTP traffic?

Say, I want to visualize what my site visitors are seeing - and I capture
complete request/reply stream of data off Ethernet interface.

------
hencq
Way back when wasn't the original plan for Seamonkey to use Gecko to render
the UI as well? Maybe they were too far ahead of their time back then.

~~~
Yoric
Yep, and most of the UI in Firefox is either XUL or HTML, both of whom are
rendered by Gecko. This is not the case on Android, for technical reasons
(libxul is too long to load, so we rely on Java, which is pre-loaded by the
OS, to display the UI).

------
earp
This is like watching a nuclear superpower go down in a fist fight. I honestly
think HTML5 was designed to eliminate Mozilla.

------
Edmond
love the idea, web tools built on web technology.

------
mcao
The one thing that absolutely annoys me about the current Firefox is the
location of the refresh button, which is a tiny icon stuck in the far right of
the location bar. Worse of all you can't customize it natively. You have to
download extensions to change the UI and still you won't get it to look 100%
how you want it. Being able to modify a HTML based UI would be awesome.

------
donniezazen
I have been running Firefox for almost a month now. The divide between firefox
and Chrome is getting bigger and bigger.

1\. What do you guys think about sidebars and multiple toolbars? There is only
a limited space available on screens these days for most people. I find them
very archaic.

2\. Dropdown arrows - I also don't understand the purpose of actually showing
that if you click here a menu will open. A folder expands when you click it.
There is nothing to be said about it.

3\. Lack of overlay icons. There is literally a block with yellow background
which shows number.

4\. Lack of interest in devs to innovate on Firefox. There is a difference in
versions of Evernote webclipper for Firefox and Chrome. Diigo extension is in
atrocious condition.

Why do you think a solid browser like Firefox is lagging behind in UI compared
to Chrome?

~~~
realusername
It depends on your point of view, I could bring up similar arguments with
Chrome. There is still no way in Chrome to open more than 25 tabs without the
tabs being so small we can't see them and the Settings page of Chrome is not
an example of clean UI either.

~~~
donniezazen
They both are great browser. I am not trying to say one is good and other is
bad. What I am trying to say is that because of the reasons mentioned above it
has been hard for me to adopt to Firefox. Chrome is Google's platform they
want to push their services and has become more of an application platform
with Chrome only apps and less of a browser. I would like a browser that
promotes a free web.

For example, Diigo's addon doesn't have overlay icon so it is impossible for
me to tell if I have already bookmarked a page or not. Like many addons on
Firefox Diigo has both sidebar and toolbar. So basically they have developed 3
UI elements and none of which work well. There is clearly Diigo's fault here
but applications are as good as platform.

