The Firefox UI Is Now Built with Web Components
briangrinstead.com
briangrinstead.com
https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
- XULRunner had an included application update mechanism. You basically created a diff between two application versions and placed that on a server. XULRunner would automatically detect it and apply it. No configuration needed. This was huge.
- XULRunner obviously had a built-in browser. Using a few XML elements, you could embed a browser view.
- Porting from a Firefox extension to a standalone application was very easy. Add some boilerplate and you are done. Pretty much no need to change the application code.
- Since my application didn't include any native code, it was automatically cross platform. And it integrated beautifully into all platforms.
The tooling was great, and it did set the precedent for what we expect today.
This had to be sometime in the mid-late 1990s?
I recall the documentation about everything was "ok-ish" - enough for me to create a simple "app" and have it communicate with a "backend" using POST (IIRC) - nothing fancy, but I could tell it actually worked.
But at the time, I had to shelve it - and I was working with a VB6 application for my employer, and I mostly forgot about it. It was always in the back of my mind, though - and I knew that Firefox, Thunderbird, etc - still had support...
Today, it was just a legacy technology that never went anywhere, and it amazes me why it didn't. It's yet another example of something "ahead of its time"; it was frustrating to me back then as to why nobody was using it and making it better - especially when there was a "reference app suite" right there!
But no - we had to wait another decade or so for everyone else to "catch up" to the concept. Sigh.
- It had all the problems of Electron in a time where memory was a much more of an issue
- Low quality documentation that didn't go into the details (although it had a great overview)
- Performance problems due to the high abstraction level and bad JS interpreter
- Memory leaking that appeared on several versions and disappeared on other versions, that randomly affected people and nobody could explain
All those problems got corrected eventually, but by then it was too late.
In the late 2000's there were many companies who launched products based on XULRunner (Miro, Songbird, Joost, Tom-Tom...), but when they encountered bugs in the platform Mozilla's response was always "bug doesn't affect Firefox, we don't care". Even if you made a PR yourself (actually a patch at the time), good luck to get it merged if Firefox wasn't impacted.
Note that XULRunner was called this way but you didn't have to use XUL, you could use HTML for UI just like in Electron today.
If Mozilla saw the potential in their platform as a development platform for third party, it might still exist and have a bigger market share than Electron today. Maybe GitHub would have used it instead of developing electron, actually.
I'll pause now for my regular appreciation of what the Visual Studio Code team have managed to do with Electron.
You know, I find myself using a substantial amount of Java desktop software.
I license JetBrains products and earn part of my living using them. DBeaver is another frequently used tool. I've spent no small amount of time in Minecraft (the Java implementation.) Java desktop software even pops up in hobbies; SimSmith is one example.
There are others. Doubtless there will be more in the future. Are we all sure Java failed on the Desktop? It certainly didn't wipe out the competing paradigms, but it's still here and still seems to work pretty well for a lot of people. There aren't any Java web browsers, but then there aren't any C# or Python web browsers either, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software.
And then there's Android......
When people say "Java failed on the desktop", it's in relation to the initial massive hype in 1995 by Sun Microsystems as the "Microsoft evil empire killer". Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit.
There was a popular Java slogan back then of "write once, run anywhere"[1]. In other words, instead of writing desktop apps that specifically target the Win32 API, you write Java & Java byte code for the Java Virtual Machine. Instead of writing raw Javascript, code in Java to run as Java applets in the web browser. This was the same time period as the slogan "the network is the computer" that Oracle's Larry Ellison was also pushing. Both Sun and Oracle were trying to minimize Microsoft Windows' dominance with Java.
So yes, even though niche desktop software like JetBrains IDEs running on Java is a reality today, it is still somewhat of a failure when it's measured against the 1990s breathless promises.
It turns out that Java was much more successful on the server side. Ebay, Amazon, Google, etc all run tons of server-side Java. It is ironic that Javascript as the "toy" language to add a little dynamic interactivity to webpages over-achieved on the desktop while Java the "serious" language under-achieved its goals for the desktop.
I'm fully aware of the history. I was there and watched it unfold at the time. I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun is dead. I'm just objectively counting the number of Java desktop programs I presently use and wondering if this supposed "failure" on the desktop isn't really just a widespread misconception. The software that I cited isn't riding the coattails of a 24 year old marketing campaign; they thrive of their own merit.
It's relevant because the context of the conversation was this gp's quote you responded to: "Back then people still thought Java would take off on the desktop."
The "back then" is referencing XUL circa ~1997. And the "Java would take off" was the ambitious idea of most desktop apps being written in Java to weaken the MS Windows ecosystem. Not only was Java hyped to be a Microsoft killer, it was also touted to be a C/C++ killer. (E.g. the idea was that computer desktops have gotten so powerful with so many wasted cpu cycles that manual memory of C/C++ is obsolete and letting GC use the excess cpu to automatically manage memory is the future.) History has now shown us that prediction didn't happen either. C/C++ is still heavily used for new desktop apps. That's a different idea than today's 2019 landscape with some niche Java apps like Jetbrains IDEs.
I do understand your point. Yes, you can also have an alternative definition of "not a failure on desktop " because you can count some current Java apps today. That's also a valid perspective. However, for the sake of not confusing the conversation... that's not what the gp was originally talking about. I don't think there's any misconception about what "Java failed on the desktop" means -- especially among the HN audience. I also regularly use Jetbrains IDEA for Android deveopment and Webstorm for Javascript but my usage of those Java apps doesn't change what "Java failed on the desktop" means to other people.
After all, how many people know something like Slack is written with a web browser engine and a massive pile of JavaScript?
There are python-webbrowsers, like qutebrowser for example. Unless you mean 100% and purely written just in python.
The same team behind Zotero has another newer application called tropy (https://tropy.org/), which is based on Electron, and apparently they were happy with that and are indeed planning to transition Zotero to Electron as well.
To add a bit more detail / a slight correction: Zotero did indeed start purely as a Firefox extension, but Zotero Standalone was released in 2011[0], far before the switch to WebExtensions. For a while, the Firefox extension and Zotero standalone were equally featured — i.e. you could use just the Firefox extension, or use Zotero standalone + the Chromium connector extension, and in both cases you'd get the same functionality. After the switch to WebExtensions, the Firefox extension was reduced to being purely a connector, just like the Chromium one.
Ironically, the use of the browser as the target for programming has, slowly, haltingly, and through nearly-infinite compromises and kludges, actually provided the working platform Smalltalk promised us Gen-Xers when we dabbled in programming as kids. I think it's ultimately for the best, even if not the ideal path to have gotten there...
[1] https://github.com/StanAngeloff/komodo-html-toolkit [2] https://github.com/StanAngeloff/komodo-fuzzy-open [3] https://github.com/StanAngeloff/komodo-aero-theme
For more details there is the famous Spolsky post about things you should never do—rewrite a product from scratch. Mozilla went one further and tried to reinvent GUI programming as well as building a new product.
In much of those days I used Netscape 4.x and it really wasn't much worse than IE. Then I used pre-1.0 Mozilla and various forks, and early firefox, they were all pretty acceptable for the time. The big issue was that all the content was authored for IE and not tested anywhere else. Monopoly.
What I wonder thoug is whether that company was able to migrate of it already or not...
It's luckily on Bugzilla, so I can keep monitoring progress daily.
1. It has its own certificate system. That would be fine if it used that in addition to using the MacOS built in system, but it seems to use it exclusively.
2. It has its own spell checker, which is orders of magnitude worse than the one provided by the native MacOS spell check API. I can't think of any program I've used in the last few years on Mac or Windows that had a worse spell checker.
LibreOffice is open source and its spell checker is fine as far as I've seen--definitely way better than the one in Firefox--so that if Mozilla for some reason needs to have the same spell check on each OS and so can't use the native MacOS one, they could still bring it up to par by copying from LibreOffice.
fwiw Chrome does this too. It's effectively standard practice for browsers - OSes routinely have very out-of-date cert stores, and don't regularly remove revoked ones. Browsers ship it separately because it's such a major security concern for browsing.
To get Chrome on MacOS to use my employer's self-signed root certificate, I just had to import it with "Keychain Access" and then both Chrome and Safari used it.
It may also have its own built-in certificate system, but for user-added certificates, it uses the built in MacOS system.
As for Firefox (on Windows), there is a setting called "security.enterprise_roots.enabled" in about:Config which you can enable or push via GPO.
From docs it appears it works on Mac too: https://support.mozilla.org/en-US/kb/setting-certificate-aut...
Firefox does not.
Curious. Both LibreOffice and Firefox use Hunspell
Which is great when it works. But Romanian (my language) is not supported by Apple (even tough they sell quite many things here).
In fact this is a good example of a dysfunctional company. Apple managed to translate to Romanian most of their help docs but they can't provide a basic spell checker.
And it's great. If you're running it portable on another machine you don't have to trust its certificates
The standard of basically every OS is that hovering the pointer over an item opens a submenu (if there's one). In Firefox, I have to click, for instance to open "Help" in the burger menu. The sub-menu then appears by replacing the parent, instead of forming a cascade near it. It's non-standard and it's slower.
The only rationale I can see for it is avoiding complex mouse paths and accidental closing of menus for absolute beginners, but still. It's not like it's not an old, solved HCI problem (see question 8). https://www.asktog.com/columns/022DesignedToGiveFitts.html
W.r.t. it being an "old, solved HCI problem", it isn't. The link you post actually posits positioning solutions to problems inherent to the hover approach. It doesn't discuss hover-vs-click at all, and while these positioning strategies still apply to some degree with the click approach, the problems they solve are much less severe there (namely, the submenu doesn't disappear if the user takes the wrong cursor route to a submenu item).
Frankly, I think it's pretty amazing that bugs this old end up getting fixed. Not many projects live even live that long, let alone keep up their infrastructure...
Our internal dev team has changed their feedback/requirements system 3 times in the last few years.
Motion without moving...
Sadly, my patch broke some custom levels which relied on the glitch. https://xkcd.com/1172/ is more true than you'd expect.
You have no idea
> Does this bug affect OS X? If not, it should be WONTFIX.
> It does affect Mac OS X.
Also, other native features are missing. Like the rubber banding and pinch to zoom, although that one works okay if you switch the config entry.
I never even noticed that it's not native until I read your comment, and looking carefully at it now the only difference I can notice is the corners are square (and that is certainly nothing worth complaining about.)
Maybe I'm just an oblivious idiot, but it sure seems to me that a lot of MacOS users on HN love to blow trivial matters completely out of proportion. Application lags for a split second? "Utter garbage, the developers should be shot, I'm going back to Safari." Where is the perspective? If there is something glaringly broken about these context menus, by all means correct me. But to my eye they look damn close to native and they seem to work perfectly fine.
Don't be so dismissive. Apart from anything, that breaks one of the HN guidelines for discussion.
Not having access to built-in and user-defined (Applescript/Automator) Services is not trivial; these are a powerful part of what makes macOS unique and a major reason why I continue to use macOS. Their lack of availability is entire down to using faked-up menus rather than proper widgets.
Having widgets behave improperly is also an accessibility issue. There are multiple accessibility APIs built into the system that practically every macOS app built using Cocoa or Carbon hook into automatically; apps that use non-native widgets that don't take enough care to (a) perfectly emulate the behaviour of native widgets or (b) sufficient expose themselves to the built-in accessibility APIs not only make for an unexpectedly unpleasant experience but also potentially are showstopping for people with disabilities.
> But to my eye they look damn close to native and they seem to work perfectly fine
In other words, it's not a problem for you, so it shouldn't be a problem for anybody else.
It's under the Firefox menu. I use it frequently to trigger an Automator service for TTS, which pipes the text through a sed script to fix common mispronunciations. I use this stuff too.
Should it be in the right click menu? Yes. Is firefox crippled by it's absence? No, because that functionality still exists, just in a different location (and if you have your services bound to keyboard shortcuts it becomes a complete non-issue.)
I stand by what I said. I'm not being unreasonably dismissive. Many mac users on this forum in particular have a habit of blowing the slightest defect completely out of proportion. Maybe they're trying to emulate Steve Jobs' infamously toxic approach to critique. Calling firefox "garbage" because of defects these minor is a prime example.
I’ve used Firefox since Chrome started threatening to block ad blockers. I have stopped recommending it.
This specific bug confused the hell out of not only my parents, but also multiple nieces and nephews in their teens. (They thought it crashes.) These age groups both spend most of their time on mobile. When a desktop app behaves unusually, it’s a massive burden.
Not fixing these bugs seems to be a cultural problem at Mozilla, albeit one that’s getting better.
Forgive me for being incredulous, but what are they using it for? While I use Services, I'm not under the impression that it's particularly common. Perhaps Mozilla haven't prioritized the matter because they, like myself, are wrong about that? (And maybe calling Firefox garbage isn't the best way to correct their cultural blindspot?)
That's the stuff I've noticed in the couple of days I've been using Firefox.
I built and managed (2009-2011) the XUL-based Elasticfox extension for Firefox that allowed users of EC2 to manage their compute resources on AWS. The extension pre-dated the AWS Console and introduced features such as resource tagging and search before they were part of the SDK.
The extension wouldn’t have been possible without XUL. In fact, it isn’t possible today. MDN documentation was really great even in those days, as was the community which answered a number of my questions. I was doing something really new, especially with calling into EC2 APIs, background refreshes, using Prefs.js to save tag information, etc., and the community was really responsive and supportive of my work. Quirks aside, my experience with XUL was great. Users truly appreciated the extension over the Java-based CLI, and a number of ideas (mine or those from the community) eventually made their way into the AWS Console.
I spent my last year at AWS working on the S3 Console using web technologies. I found XUL development to be easier than hacking CSS that year (circa 2010-11).
Edit: Added a note up top that this is my XUL story.
Without looking at the source-code: Doesn't this problem still exist, just in a different form? You're still running some kind of browser instance to render the UI, rather than using native methods.
Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.
I have to say I feel a bit old hearing developers say "well why didn't the OS developers provide common APIs for creating applications?" which in my mind, is asking why Toyota Corollas and Ford F-150's don't use the same engine. The answer being they were two entire universes, and still are to a great degree.
That being said, while it is desirable to have standard API endpoints that are accessible, and while standards in general are a Good Thing(tm) to have, it does get a bit tiresome to hear different companies like Spotify[1], especially of that scale, bemoaning that they simply "must" use frameworks like Electron to build their applications because developing for individual platforms is just too expensive. If you want your application available on multiple platforms, and you want it to be a good experience to use, then you should be developing bespoke applications for them. That's just... logic, to me.
Yeah, it's more work. But to take a crap ton of web-content, shove it in a .app file and distribute that is massively wasteful, lazy, and results in what that kind of effort typically nets: bad experiences.
For example: I absolutely LOVE the Atom editor. It's a fantastic tool to use. That said I've had to give it up because it was simply killing my Mac's performance, a brand new, 2019, 15" Macbook Pro would sit there spinning it's fans up whenever it was on the screen, for a text editor. A feature rich text editor to be sure, but this thing can play 4K movies without even running the fans. A text editor should not strain it. I can't help but feel Electron is playing a role here.
[1]: I have no idea if Spotify uses Electron. I just know they've complained about this before.
Yeah, they're now a weaker (browser) engine bolted on with adapters to the gui engine. Everyone gets to go through the js bottleneck.
This is a bug, not a feature.
[1]: https://github.com/status-im/react-native-desktop [2]: https://github.com/kusti8/proton-native
Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.
That's what you get with Qt absent the moc (meta object compiler).
Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.
So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.
but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.
what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox.
Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, hell even notepad++ in all its "non-intelligence" manages to.
> Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.
I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.
> I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.
My point does make sense, you're just missing it.
First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.
Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.
If that was the case, gcc and clang would not be able to build Qt files. Yet the following compiles without issues :
echo "#include <QObject>\nstruct foo : QObject { signals: void bar(); public slots: void blah() { } };" | g++ -std=c++11 -fPIC -I /usr/include/qt/QtCore -c -x c++ -
hell, you can even generate the signals code without moc if you are ok with more macros (https://github.com/woboq/verdigris)
I'm a little bummed that this loophole is going away in FF 72 (I still can't get pre-Lion fullscreen!). On the other hand, it has always been super clear that this is a loophole that will eventually go away, and I did get 2 years of use out of it, so I'm not complaining too loudly. Congrats to the team for removing XBL!
Just enough abstraction to automate the hard stuff without dictating your architecture.
Good god.I've seen some ridiculous tab collections but that is next level.
I never use multiple windows in any browser because they are unreliable with tab reloading.
I know for example the devtool is written in react and it's a lot slower than chrome devtools (I don't know how chrome devtool is written) and the javascript debugger is sometime not even usable because it's so slow.
We've focused on performance and quality over the past six months and believe it should be much better.
If you're still seeing issues, feel free to record a performance profile and send it to us:
- https://profiler.firefox.com/ - https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&...
I'd be happy to fix it!
Performance-wise it's been running great for me. The hard work you've put into this definitely shows.
https://github.com/ChromeDevTools/devtools-frontend/blob/mas...
then you should have additional entries in the tools -> web developer menu.
On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript.
On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> that in the background creates all the canvases and such needed will be neat.
This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.
LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
https://github.com/Polymer/lit-html/wiki/How-it-Works#4-upda...
Excerpt:
update() simply iterates through each part and value (the parts array and values array are always the same length) and calls part.setvalue(v) for each part.
https://lit-html.polymer-project.org/guide
Excerpt:
Behind the scenes lit-html creates HTML <template> elements from your JavaScript templates and processes them so that it knows exactly where to insert and update the values from expressions.
This is very limited. You need to manually update DOM unless your updates are simple changes in values of expressions.
lit-html updates only the parts of DOM that are dynamic and change. It handles nested templates as values, only updating the whole nested template if the template itself changes, otherwise recursing and only updating that template's values if needed. Repeated DOM is handled either by simply updating state for each item in sequence (non-keyed), or by using the repeat() directive which will move DOM (keyed).
You absolutely don't need to manually update DOM. The whole point is to describe your DOM structure as a function of data, and to be to describe all the conditional / repeated parts in the template expression itself.
Where is the plug-in that does compile-time checks of HTML tags and attributes?
This is the tsc plugin: https://www.npmjs.com/package/ts-lit-plugin
If you look at https://lit-element.polymer-project.org — it's just a base class that integrates declarative DOM templates.
The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)
I just couldn't stand the blurry text, so now I'll give it a go and switch back to Firefox. Although, the colors look far more saturated than they should be, like the orange Hacker News navigation bar.
I'm not that weird about change and normally accept it and end up not caring. But I have tried to get used to tabs on top and it just isn't happening. If I can no longer have that I guess I will need to get used to Safari. Or I will just keep using Firefox and not update and accept the security implications.
Anyway - nightly is a dev build. It is expected to have bugs of all kinds.
To me it seems many hundreds, if not thousand, man years spent on something totally unnecessary.
Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.
Does this strip away a layer of security?
So this should help Firefox be more secure, by decreasing attack surface.
> There are hard to debug complications with binding lifecycles in our UI, and very few people know how it works.
> It adds enormous complexity to our platform in the frame constructor, style system, and the DOM implementation.
Especially when receiving generally untrusted input from the internet (websites, extensions, web-workers in this case) and you're suppose to display/use that somehow.
One of the reasons I prefer Safari on macOS is that it actually has a native Cocoa UI.
I can just imagine it would be easy to build up a very large mess ...
/user researcher (etc.)
Plus I don't need half a dozen chromium processes just to run it
Let's just say that beauty is in the eye of the beholder :)
> Plus I don't need half a dozen chromium processes just to run it
Yeah, I'll grant you that. Native UI is mostly likely more memory and cpu efficient.
Were you using Nightly?
If not, then it's most probably unrelated.
> Firefox has always been built with DOM, JS, CSS technologies, as the linked article calls out
I am aware of that (and imo, it was a mistake). That however does not mean that moving to more web-y stuff will not make the performance any worse.
https://mozilla.github.io/firefox-browser-architecture/text/... says:
> XBL is a proprietary technology developed by Mozilla. We are solely responsible for the maintenance and improvement of XBL. Any time spent on doing this doesn’t contribute to the evolution of the Web so effectively we don’t spend anytime improving XBL except for plugging serious holes.
What they mean is they 'own' it, the good, the tedious and the bad parts.