Live data from Hacker News

The Firefox UI Is Now Built with Web Components

briangrinstead.com

81–90 of 260 posts

Re: The Firefox UI Is Now Built with Web Components

#81

XUL was ahead of its time when it was introduced by Netscape/Mozilla many years ago. It was a capable XML based language used to describe rich graphical user interfaces. Together with XULRunner this was supposed to be a generic framework for creating graphical applications. This was long before HTML became what it is today. Back then people still thought Java would take off on the desktop. I believe that most Mozilla…

I recall playing with it, when I first heard about it: "You mean I can create a native-looking app that's actually browser-based?"...

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.

Re: The Firefox UI Is Now Built with Web Components

#83
post #51

I'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS. It's luckily on Bugzilla, so I can keep monitoring progress daily. https://bugzilla.mozilla.org/show_bug.cgi?id=34572

Ticket opened 20 years ago, damn.

There was a very old ticket that was closed recently when a component was re-written in Rust. I can't find a link right this second, but if you could have told the future, it's kinda amusing. "Sorry, we'll fix this, but first we have to invent a new programming language. We'll get back to you in a decade."

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...

Re: The Firefox UI Is Now Built with Web Components

#86
post #51

I'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS. It's luckily on Bugzilla, so I can keep monitoring progress daily. https://bugzilla.mozilla.org/show_bug.cgi?id=34572

In which ways is the Firefox context menu "garbage"? How does it behave differently?

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.

Re: The Firefox UI Is Now Built with Web Components

#87

Earlier quoted context omitted.

You can still have race conditions in single-threaded async code.

Well I don't think that could technically be considered a race condition, as it's clearly a design problem in the code causing what would appear to be a "pseudo" race condition.

Why not? It is a race condition, just like TOCTTOU is a race condition that doesn't necessarily involve threads.

Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.

Re: The Firefox UI Is Now Built with Web Components

#88
post #51

I'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS. It's luckily on Bugzilla, so I can keep monitoring progress daily. https://bugzilla.mozilla.org/show_bug.cgi?id=34572

In which ways is the Firefox context menu "garbage"? How does it behave differently? 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 matter…

They don't close when you release right-click, they don't contain services, they don't select the word you are on.

That's the stuff I've noticed in the couple of days I've been using Firefox.

Re: The Firefox UI Is Now Built with Web Components

#89
post #51

I'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS. It's luckily on Bugzilla, so I can keep monitoring progress daily. https://bugzilla.mozilla.org/show_bug.cgi?id=34572

In which ways is the Firefox context menu "garbage"? How does it behave differently? 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 matter…

Here's one: try right clicking and dragging out. Firefox's menu will open and stay open.

Re: The Firefox UI Is Now Built with Web Components

#90

Earlier quoted context omitted.

Firefox has always been built with DOM, JS, CSS technologies, as the linked article calls out. This change replaces a large proprietary extension, XBL, with a standard equivalent.

Calling XBL a proprietary is weird when considering that it is published by w3c and that firefox is FOSS. > 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.

The language is official.

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.

Post reply on HN