What I don't understand is why Firefox still hasn't moved to native UI widgets across platforms. Especially on a Mac or Unix machine, where software behaves largely consistently, the difference is...
What I don't understand is why Firefox still hasn't moved to native UI widgets across platforms. Especially on a Mac or Unix machine, where software behaves largely consistently, the difference is notable and it rankles. Privacy issues notwithstanding, I prefer Chrome / Chromium to Firefox because the former behaves more like a native application than Firefox does.
TBH, most browsers need to draw their own variants of UI widgets for various reasons. Obviously some are more pixel-perfect than others. In the Firefox case, until October of this year I worked on...
Exemplary
TBH, most browsers need to draw their own variants of UI widgets for various reasons. Obviously some are more pixel-perfect than others.
In the Firefox case, until October of this year I worked on the team that is more or less responsible for UI widget drawing. While I didn't work on it directly, I do have a bit of insight into this.
One of the problems in Gecko is that sandboxed content processes draw their own UI widgets. Since the content processes are sandboxed, and since we are constantly looking for ways to tighten the screws on those sandboxes, content processes do not (and should not) have access to the widget drawing libraries of the host platform.
This leaves developers with various options:
Content processes leverage their own rendering engine to render UI widgets, using HTML and CSS in an effort to emulate the native UI widgets;
Similar to (1), except the parent process retrieves theming information from the OS and sends it down to the content process to use for rendering;
Content processes send IPC messages up to the parent process and request the parent process to draw the UI widgets on content's behalf.
Each option has its advantages and disadvantages, and of course a huge factor in these types of decisions comes down to technical debt.
I have no doubt that the implementation of UI widgets will continue to improve over time, but as with a lot of decisions in large software projects, there's always a lot more going on under the hood than meets the eye.
Thank you for the detailed response! You're right, there is more going on than one can easily see, and also there are tradeoffs as well. I would have made different choices, clearly, so I wonder...
Thank you for the detailed response! You're right, there is more going on than one can easily see, and also there are tradeoffs as well. I would have made different choices, clearly, so I wonder what the reasoning was for choices 1 and 2 above.
A lot of what I alluded to in terms of "technical debt" comes down to the fact that Gecko was initially a uniprocess rendering engine, so its original design makes many assumptions about what its...
A lot of what I alluded to in terms of "technical debt" comes down to the fact that Gecko was initially a uniprocess rendering engine, so its original design makes many assumptions about what its process can do -- in other words, older code tends to assume that it can do pretty much anything a normal process can do, because it had no concept of a sandbox.
Making the sandbox more stringent is actually the easy part. The difficult part is taking the parts of Gecko that don't work correctly anymore (because they are trying to access OS services that are no longer available to them), and modifying them to work inside that sandboxed environment.
Sometimes those changes are complicated enough that there might be trade-offs to be made.
As a hypothetical possibility, maybe somebody had to decide what was more important to ship in a given release: pixel-perfect UI widgets or a more stringent sandbox. If pwn2own was coming up, I'd personally opt for the sandbox. (To reiterate, this is a completely hypothetical scenario intended to illustrate the decisions that need to be made)
Everything. None of the widgets look or behave the same way as native ones do. Buttons don't look like or act like buttons, scrolling feels weird (largely because it isn't elastic), text is...
Everything. None of the widgets look or behave the same way as native ones do. Buttons don't look like or act like buttons, scrolling feels weird (largely because it isn't elastic), text is antialiased differently on Unix platforms, and so on. It's like using an Electron app; it has that cheap, lazy feeling to it, like the developers wanted something that worked for them instead of what's better for their users (you know, what a software developer should be doing).
It's hard to give specific examples when it's the entire thing that's the problem.
What I don't understand is why Firefox still hasn't moved to native UI widgets across platforms. Especially on a Mac or Unix machine, where software behaves largely consistently, the difference is notable and it rankles. Privacy issues notwithstanding, I prefer Chrome / Chromium to Firefox because the former behaves more like a native application than Firefox does.
TBH, most browsers need to draw their own variants of UI widgets for various reasons. Obviously some are more pixel-perfect than others.
In the Firefox case, until October of this year I worked on the team that is more or less responsible for UI widget drawing. While I didn't work on it directly, I do have a bit of insight into this.
One of the problems in Gecko is that sandboxed content processes draw their own UI widgets. Since the content processes are sandboxed, and since we are constantly looking for ways to tighten the screws on those sandboxes, content processes do not (and should not) have access to the widget drawing libraries of the host platform.
This leaves developers with various options:
Each option has its advantages and disadvantages, and of course a huge factor in these types of decisions comes down to technical debt.
I have no doubt that the implementation of UI widgets will continue to improve over time, but as with a lot of decisions in large software projects, there's always a lot more going on under the hood than meets the eye.
Thank you for the detailed response! You're right, there is more going on than one can easily see, and also there are tradeoffs as well. I would have made different choices, clearly, so I wonder what the reasoning was for choices 1 and 2 above.
A lot of what I alluded to in terms of "technical debt" comes down to the fact that Gecko was initially a uniprocess rendering engine, so its original design makes many assumptions about what its process can do -- in other words, older code tends to assume that it can do pretty much anything a normal process can do, because it had no concept of a sandbox.
Making the sandbox more stringent is actually the easy part. The difficult part is taking the parts of Gecko that don't work correctly anymore (because they are trying to access OS services that are no longer available to them), and modifying them to work inside that sandboxed environment.
Sometimes those changes are complicated enough that there might be trade-offs to be made.
As a hypothetical possibility, maybe somebody had to decide what was more important to ship in a given release: pixel-perfect UI widgets or a more stringent sandbox. If pwn2own was coming up, I'd personally opt for the sandbox. (To reiterate, this is a completely hypothetical scenario intended to illustrate the decisions that need to be made)
What differences you have noticed?
Everything. None of the widgets look or behave the same way as native ones do. Buttons don't look like or act like buttons, scrolling feels weird (largely because it isn't elastic), text is antialiased differently on Unix platforms, and so on. It's like using an Electron app; it has that cheap, lazy feeling to it, like the developers wanted something that worked for them instead of what's better for their users (you know, what a software developer should be doing).
It's hard to give specific examples when it's the entire thing that's the problem.
(Not OP) On macOS: Mostly scrolling and the context menu