28 ms·

Firefox.html: Rebuilding Firefox UI in HTML

609 points by ash 12y ago

icefox 12y ago
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
- passwordis 12y ago
  HTML and joy in the same sentence. Whoa
  - oatmealsnap 12y ago
    Why?
- of 12y ago
  What is that browser called?
  - icefox 12y ago
    Hmm didn't really have a name as it was the browser that was included and just called "Browser" if I recall.
- icefox 12y ago
  Another very cool feature I forgot about was that when developing the browser application on the device it would not actually have any browser bits on the device, but just have the environment variable CHROME_URL set to my desktop where I had a webserver serving up my browser files. This let me very rapidly develop the html/css/javascript code without having to transfer my "mobile app" to the device. Reducing the edit/"compile"/see cycle was a big win.
- soapdog 12y ago
  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 12y ago
    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.
- icefox 12y ago
  Slides for the presentation: http://hosting.desire2learncapture.com/RIM/Content/attachments/Archive/50/JAM56.pdf http://hosting.desire2learncapture.com/RIM/Content/attachmen...
- mdm_ 12y ago
  I switched to BlackBerry from Android last year and the browser is amazing (composing this reply with it on my Passport). Just wanted to say thanks!
misuba 12y ago
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 12y ago
  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.
Morgawr 12y ago
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?
- lamacase 12y ago
  > What is rendering that HTML if not a browser? I don't think the search-box and tabs are rendering it. The firefox interface is already described in an XML format (XUL) and rendered from that. Instead of having two markups and two renderers, this allows you to simplify and consolidate to a single one. I would hardly construe that as having "gone too far".
- Igglyboo 12y ago
  >What is rendering that HTML if not a browser? The browser is rendering it's own UI.
- towelguy 12y ago
  Dogfooding?
- michielvoo 12y ago
  > 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.
  - 12y ago
kibwen 12y ago
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-October/007160.html https://lists.mozilla.org/pipermail/dev-platform/2014-Octobe...
paulrouget 12y ago
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.
- lucianmarin 12y ago
  Why don’t you use SVG instead of PNG for icons? Then you can use CSS to customize them for different themes.
  - paulrouget 12y ago
    I want to use SVG. See issue #24. I just don't have the assets.
    - apaprocki 12y ago
      It might even make more sense to just use fonts for the icons and leave SVG out of it entirely. I'm referring to the OpenType COLR/CPAL tables Microsoft is pushing: http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ http://opentype.info/blog/2013/07/03/color-emoji-in-windows-...
      - talmand 12y ago
        Personally, I'd prefer SVG over fonts unless they change how using font icons is done in HTML and CSS.
      - desdiv 12y ago
        I was looking for a similar solution recently, and came across Stackicons[0], basically icon fonts with multiple color layers, essentially what Microsoft is proposing. But there's a huge flaw with the whole approach: you can't have color gradients. Of course you can still emulate gradients by using lots of layers, but it's going to look like crap when you increase the resolution. [0] http://stackicons.com/ http://stackicons.com/
agumonkey 12y ago
I'm always pleased when I use chrome devtools on chrome devtools. So I can't welcome this enough. Have fun.
- kbrosnan 12y ago
  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#Settings https://developer.mozilla.org/en-US/docs/Tools/Tools_Toolbox...
  - agumonkey 12y ago
    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.
bkeroack 12y ago
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.
- nevir 12y ago
  Rendering perf is catching up
- frik 12y ago
  Similar concepts from Microsoft (browser wars era): Microsoft integrated Trident (Internet Explorer HTML engine) to Win95 with the ActiveDesktop refresh (part of IE4 installation) and shipped with Win98 by default. The desktop background wallpaper was a large HTML page, there were DHTML widgets, the Explorer sidebar was HTML. In Windows 2000 and ME you could even preview Videos in the HTML based sidebar. WinXP's sidebar is HTML based too, also the slow applications window where you can uninstall applications, as well as the control panel. Even in Win7 and more modern versions the UI render code for the control panel, some new popup dialogs, and some Office UI and Windows Media Player is based on a forked render code that happened in the XP era. The EU even mandated that Microsoft has to release the API to the public, so that other developers could create such beautiful Windows applications based on that UI code. Use your favorite PE resource explorer (e.g. reshacker) to verify it. The DHTML source is in various shell related dlls in the Windows directory.
- cwyers 12y ago
  I'm pretty sure Firefox has used XUL during its entire lifespan; Camino is the Mozilla browser that used native GUI. http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.html http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.h...
hencq 12y ago
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 12y ago
  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).
1ris 12y ago
Is this the first step to switch to servo?
- Yoric 12y ago
  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 12y ago
    Can you link to the pull request? I'm curious to see it, but can't find it.
    - Yoric 12y ago
      https://github.com/paulrouget/firefox.html/pull/17 https://github.com/paulrouget/firefox.html/pull/17
grumblestumble 12y ago
I'm all for it if it means we finally get ::-webkit-scrollbar equivalency in Firefox...
phkahler 12y ago
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 12y ago
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-retrospective/#porting-method http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...
nacs 12y ago
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
espadrine 12y ago
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 12y ago
  weaknesses: I built it in a couple of days. It's ugly. Designed for Firefox.html only. Don't use it :)
  - voltagex_ 12y ago
    How did you build it? I always thought the Firefox code was huge and monolithic and couldn't be used like this.
    - espadrine 12y ago
      The main commit seems to be this: https://github.com/paulrouget/gecko-dev/commit/a3bb11e9bcf8cf48184c522f9c1856d79db5025e https://github.com/paulrouget/gecko-dev/commit/a3bb11e9bcf8c... You may notice a thin layer of XUL.
shmerl 12y ago
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 12y ago
  Firefox OS on the otherhand is HTML.
  - shmerl 12y ago
    Yeah. So I wonder if Mozilla is going to switch to HTML UI on other mobile platforms too.
twtwtaway 12y ago
So will I be able to use Chrome and open firefox in it?
simonw 12y ago
Would it be possible to implement XUL using Web Components and port the existing XUL interface to HTML that way?
- fnump 12y ago
  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.
matthewmacleod 12y ago
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.
taf2 12y ago
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
- tracker1 12y ago
  You should look into atom-shell and node-webkit... both are nice options if you want a cross-platform UI app with html+css+js.
- adl 12y ago
  > 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"
  - taf2 12y ago
    see it's crazy. I don't know how to relate and I see it's the same for you. To me there's nothing easier than building UI in HTML with CSS and JavaScript. Using code to tweak padding and positioning in native code with a compile step is much slower IMO then 10.times { alt+tab, edit, cmd+r } -> perfect [edit] - i should mention I spent a lot of time building desktop apps but haven't put much time into the newer mobile apps ios or android maybe it's improved a lot in ten years? [edit] - last edit, I know it's improved and I suspect it's a matter of taste and proficiency that makes the difference.
mcao 12y ago
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.
Edmond 12y ago
love the idea, web tools built on web technology.
agumonkey 12y ago
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/firefoxhtml_rebuilding_firefox_ui_in_html_paul/cmr81pl http://www.reddit.com/r/programming/comments/2ow1g0/firefoxh...
browserxul 12y ago
Copy this into firefox's URL bar for a fun treat: chrome://browser/content/browser.xul
- ehsanu1 12y ago
  Nice, and it nests too! Though with strange behavior after the first nesting.
gesman 12y ago
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.
donniezazen 12y ago
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 12y ago
  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 12y ago
    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.
blueskin_ 12y ago
>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 12y ago
  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.
earp 12y ago
This is like watching a nuclear superpower go down in a fist fight. I honestly think HTML5 was designed to eliminate Mozilla.

609 points by ash 12y ago

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

passwordis 12y ago
HTML and joy in the same sentence. Whoa
- oatmealsnap 12y ago
  Why?
of 12y ago
What is that browser called?
- icefox 12y ago
  Hmm didn't really have a name as it was the browser that was included and just called "Browser" if I recall.
icefox 12y ago
Another very cool feature I forgot about was that when developing the browser application on the device it would not actually have any browser bits on the device, but just have the environment variable CHROME_URL set to my desktop where I had a webserver serving up my browser files. This let me very rapidly develop the html/css/javascript code without having to transfer my "mobile app" to the device. Reducing the edit/"compile"/see cycle was a big win.
soapdog 12y ago
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 12y ago
  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.
icefox 12y ago
Slides for the presentation: http://hosting.desire2learncapture.com/RIM/Content/attachments/Archive/50/JAM56.pdf http://hosting.desire2learncapture.com/RIM/Content/attachmen...
mdm_ 12y ago
I switched to BlackBerry from Android last year and the browser is amazing (composing this reply with it on my Passport). Just wanted to say thanks!

misuba 12y ago

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 12y ago
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.

Morgawr 12y ago

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?

lamacase 12y ago
> What is rendering that HTML if not a browser? I don't think the search-box and tabs are rendering it. The firefox interface is already described in an XML format (XUL) and rendered from that. Instead of having two markups and two renderers, this allows you to simplify and consolidate to a single one. I would hardly construe that as having "gone too far".
Igglyboo 12y ago
>What is rendering that HTML if not a browser? The browser is rendering it's own UI.
towelguy 12y ago
Dogfooding?
michielvoo 12y ago
> 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.
- 12y ago

kibwen 12y ago

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-October/007160.html https://lists.mozilla.org/pipermail/dev-platform/2014-Octobe...

paulrouget 12y ago

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.

lucianmarin 12y ago
Why don’t you use SVG instead of PNG for icons? Then you can use CSS to customize them for different themes.
- paulrouget 12y ago
  I want to use SVG. See issue #24. I just don't have the assets.
  - apaprocki 12y ago
    It might even make more sense to just use fonts for the icons and leave SVG out of it entirely. I'm referring to the OpenType COLR/CPAL tables Microsoft is pushing: http://opentype.info/blog/2013/07/03/color-emoji-in-windows-8-1-the-future-of-color-fonts/ http://opentype.info/blog/2013/07/03/color-emoji-in-windows-...
    - talmand 12y ago
      Personally, I'd prefer SVG over fonts unless they change how using font icons is done in HTML and CSS.
    - desdiv 12y ago
      I was looking for a similar solution recently, and came across Stackicons[0], basically icon fonts with multiple color layers, essentially what Microsoft is proposing. But there's a huge flaw with the whole approach: you can't have color gradients. Of course you can still emulate gradients by using lots of layers, but it's going to look like crap when you increase the resolution. [0] http://stackicons.com/ http://stackicons.com/

agumonkey 12y ago

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

kbrosnan 12y ago
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#Settings https://developer.mozilla.org/en-US/docs/Tools/Tools_Toolbox...
- agumonkey 12y ago
  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.

bkeroack 12y ago

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.

nevir 12y ago
Rendering perf is catching up
frik 12y ago
Similar concepts from Microsoft (browser wars era): Microsoft integrated Trident (Internet Explorer HTML engine) to Win95 with the ActiveDesktop refresh (part of IE4 installation) and shipped with Win98 by default. The desktop background wallpaper was a large HTML page, there were DHTML widgets, the Explorer sidebar was HTML. In Windows 2000 and ME you could even preview Videos in the HTML based sidebar. WinXP's sidebar is HTML based too, also the slow applications window where you can uninstall applications, as well as the control panel. Even in Win7 and more modern versions the UI render code for the control panel, some new popup dialogs, and some Office UI and Windows Media Player is based on a forked render code that happened in the XP era. The EU even mandated that Microsoft has to release the API to the public, so that other developers could create such beautiful Windows applications based on that UI code. Use your favorite PE resource explorer (e.g. reshacker) to verify it. The DHTML source is in various shell related dlls in the Windows directory.
cwyers 12y ago
I'm pretty sure Firefox has used XUL during its entire lifespan; Camino is the Mozilla browser that used native GUI. http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.html http://www-archive.mozilla.org/roadmap/roadmap-02-Apr-2003.h...

hencq 12y ago

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 12y ago
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).

1ris 12y ago

Is this the first step to switch to servo?

Yoric 12y ago
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 12y ago
  Can you link to the pull request? I'm curious to see it, but can't find it.
  - Yoric 12y ago
    https://github.com/paulrouget/firefox.html/pull/17 https://github.com/paulrouget/firefox.html/pull/17

grumblestumble 12y ago

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

phkahler 12y ago

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 12y ago

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-retrospective/#porting-method http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

nacs 12y ago

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

espadrine 12y ago

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 12y ago
weaknesses: I built it in a couple of days. It's ugly. Designed for Firefox.html only. Don't use it :)
- voltagex_ 12y ago
  How did you build it? I always thought the Firefox code was huge and monolithic and couldn't be used like this.
  - espadrine 12y ago
    The main commit seems to be this: https://github.com/paulrouget/gecko-dev/commit/a3bb11e9bcf8cf48184c522f9c1856d79db5025e https://github.com/paulrouget/gecko-dev/commit/a3bb11e9bcf8c... You may notice a thin layer of XUL.

shmerl 12y ago

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 12y ago
Firefox OS on the otherhand is HTML.
- shmerl 12y ago
  Yeah. So I wonder if Mozilla is going to switch to HTML UI on other mobile platforms too.

twtwtaway 12y ago

So will I be able to use Chrome and open firefox in it?

simonw 12y ago

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

fnump 12y ago
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.

matthewmacleod 12y ago

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.

taf2 12y ago

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

tracker1 12y ago
You should look into atom-shell and node-webkit... both are nice options if you want a cross-platform UI app with html+css+js.
adl 12y ago
> 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"
- taf2 12y ago
  see it's crazy. I don't know how to relate and I see it's the same for you. To me there's nothing easier than building UI in HTML with CSS and JavaScript. Using code to tweak padding and positioning in native code with a compile step is much slower IMO then 10.times { alt+tab, edit, cmd+r } -> perfect [edit] - i should mention I spent a lot of time building desktop apps but haven't put much time into the newer mobile apps ios or android maybe it's improved a lot in ten years? [edit] - last edit, I know it's improved and I suspect it's a matter of taste and proficiency that makes the difference.

mcao 12y ago

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.

Edmond 12y ago

love the idea, web tools built on web technology.

agumonkey 12y ago

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/firefoxhtml_rebuilding_firefox_ui_in_html_paul/cmr81pl http://www.reddit.com/r/programming/comments/2ow1g0/firefoxh...

browserxul 12y ago

Copy this into firefox's URL bar for a fun treat: chrome://browser/content/browser.xul

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

gesman 12y ago

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.

donniezazen 12y ago

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 12y ago
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 12y ago
  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.

blueskin_ 12y ago

>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 12y ago
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.

earp 12y ago

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