Hacker News Reader

Comment by leeoniya | Hacker News Reader

i just want to say, Firefox is seriously fast now, while Chrome continues to get slower [1].

my 10M datapoint uPlot benchmark runs in half the time, for both pure js (fake data gen) and canvas workloads (chart rendering). check out the console in [2].

however, i'm still waiting for the performance assessment in devtools to improve so i can get an easy summary as i can in Chrome.

also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\

[1] https://github.com/krausest/js-framework-benchmark/issues/68...

[2] https://leeoniya.github.io/uPlot/bench/uPlot-10M.html

View on HN

> also, better default form input styling would be nice. it's so...Windows 98....but i'm on Windows 10. :\

Google and Microsoft seem to agree with you, but I totally don't get it!

If the website doesn't specify a style, my browser should fall back to a design that matches my OS, not whatever the browser developer thought was pretty!

And if Windows is coming back and telling the browser to use Windows 98 styled buttons, Microsoft should fix Windows!

> The underlying problem is Windows suggesting Windows 98 styled buttons. Microsoft should fix Windows.

i think that's the canned WONTFIX response for every bugzilla issue ever closed about it in the past, what, 7 years?

...but does that make it wrong?

> The underlying problem is Windows suggesting Windows 98 styled buttons

I'm almost positive that Firefox doesn't use OS-native controls; they've specifically styled their controls to look the way they do, so yes, this is a Firefox problem, not a Windows problem.

Really? The reason I assumed otherwise is that, the buttons on Mac look like Mac buttons to me. And furthermore, the buttons on my Mavericks Mac (pre Apple's flat redesign) look different than the ones on my High Sierra Mac.

I think it's an imitation. They're not stock UI elements. For example, on my Mojave system, if I just make an HTML button, I can see it doesn't respect the systemwide dark setting, the highlight color looks slightly darker than a normal light-theme button and it doesn't invert the text color when highlighted.

In dark mode, buttons have a darker highlight and don't invert their text color.

Safari on windows were showing osx-styled default buttons, so I think safari also implement their own UI controls, not using system's ui elements.

That’s because Safari was ported to Windows by porting a large chunk of AppKit to Windows - it didn’t make direct use of Win32.

Wow this is interesting! Does that means technically we could have any OSX app compiled for windows while still retaining OSX-like appearance? Did Apple ever released this AppKit windows port for others to use? Does apple still maintaining the port for MacOS as well or did it die along with Safari for windows?

Before NeXT was acquired by Apple, they had OpenSTEP running on top of Windows. Back in the day, you could run a NeXTSTEP app on NeXT hardware, Sun hardware as well as x86: https://en.wikipedia.org/wiki/OpenStep#OPENSTEP_Enterprisee

It was originally ported for and is still used in iTunes.

iTunes uses CoreFoundation but it kinda barely uses AppKit even on macOS.

Please do no try to make osx-like appearance on Windows. It's too alien

Safari buttons on macOS are native unless you style them in a way that causes their font or size to change.

They are not OS-native, but they use OS theming information.

Right. Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. But Firefox is trying to emulate the look and feel of the OS controls, using native theme drawing APIs when possible. It is very hard to get 100% right, which is why no browser does.

Huh. I wonder if that applies even to Safari on Mac and iOS, given how integrated Apple likes to be with their UI controls.

Some of them are native, if you don't style them.

That isn't true. Browsers reimplement the native look and feel (in some cases) but they do not use the actual native control implementation.

Safari on macOS uses native controls. The reply button I'm about to click to submit this comment is 100% native, because Hacker News is using nothing fancy beyond <input type="submit" value="reply">. (Interestingly, Safari will outright ignore font sizes it cannot draw a native control for…)

To understand this better, here's a good place to start in the Webkit source code: https://github.com/WebKit/webkit/blob/master/Source/WebCore/... That is the interface Webkit uses to draw "native theme" buttons and other controls on Mac. It is not using a real Cocoa NSButton for each button in the Web page. Instead, it creates its own internal DOM and CSS rendering objects (HTMLButtonElement, RenderButton respectively) which are cross-platform code. Every time it needs to draw a button, it calls virtual methods on RenderTheme. On Mac, the RenderThemeMac implementation calls down into Cocoa code to draw the background and borders of the button. (But not text; that wouldn't work in general, because in HTML a <button> can contain arbitrary HTML elements, and native buttons can't handle that.) That's pretty much the only involvement of Cocoa native button code. Firefox works in a very similar way; here's the Firefox version of RenderThemeMac: https://github.com/mozilla/gecko-dev/blob/master/widget/coco...

I am only familiar with WebKit, but glancing at the Firefox code, it looks quite similar. I'm actually not sure what you're claiming? Both implementations rely on NSButtonCell to perform button rendering when possible, and fall back on drawing it by hand if you mess with it too much (for example, if you set background-color: green on it). Then it hooks up internal DOM objects so they can be manipulated using web APIs.

I think I was pretty clear up above:

> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. But Firefox is trying to emulate the look and feel of the OS controls, using native theme drawing APIs when possible.

Then Wowfunhappy wrote: "I wonder if that applies even to Safari on Mac and iOS". It absolutely does, Firefox and Safari work the same way here. But you appeared to think you were contradicting us when you wrote "Some of them are native, if you don't style them."

I guess it boils down to what you mean by "Safari on macOS uses native controls." Drawing with NSButtonCell and the other theme APIs does not, in my view, warrant such a blanket statement. All of the interactive behaviour of buttons and other widgets is (re)implemented by Webkit/Gecko. Accessibility is reimplemented. Layout is reimplemented. It's only painting that uses NSButtonCell, and not all painting either (borders and background but not the text).

I would certainly never claim "Firefox on MacOS uses native controls" even though it works pretty much the same way as Safari.

I would call that quite native, because you can see what they do when they can't actually use the platform APIs. In my mind, blitting pixels onto a screen is non-native; using a NSView/NSCell or similar "generic" view and drawing into that wouldn't really cut it either, but using an actual button cell is basically as native as you get. Like, that platform API exists for exactly the thing Safari and Firefox are using it for? I'm not saying that they're rendering and interacting with the web natively–that would mean they're translating divs into NSViews and text into text components–but for controls they are using honest-to-goodness AppKit controls that they have hooked up to web APIs. What is not native is what they do when you mess with them, as I described.

The drawing code is not what people typically mean by "native". What they mean is the behavior. No browser relies on the built-in behavior of e.g. an NSButton. The source code of "native" Mac apps looks nothing like RenderThemeMac.cpp.

On macOS the situation is interesting because there is a sort of an “in-between” later that doesn’t really seem to exist on other platforms, which is cells. Usually you either have a control or you have a drawing primitive and you get nothing in between, but on macOS you have a class that encapsulates the drawing portion of a control and you can hook up your own event system on top of it. Safari has it a little bit more complicated than this because it needs to handle basically every possible abuse of NSButtonCell before it falls back to something completely custom; Mac apps typically don’t style their buttons in a dozen different ways. Safari can’t actually use NSButton because such a class obviously can’t be hooked up to the DOM: it wouldn’t be worth it. But if Safari actually included a full reimplementation of NSButton, it would be significantly more complicated than what we see here. It is still relying on a lot of NSButtonCell functionality, which as you mention is just drawing but includes behaviors like highlights and sizing and animation which people who actually do try to reimplement have historically done poorly. (Actually, to be completely honest, Safari actually does break a couple of things as it tries to disable built-in behaviors. But this is coming at it from the opposite direction from usual.) I know it isn’t sending NSEvents around but it “feels native” and works with the web: it looks, acts, and even updates like a button but makes an event in the web page, which is I think the best anyone can do. (FWIW, iTunes does its own thing too, and it’s native as well. It’s just bad native.) At some point, when they’re using a significant portion of the platform’s native control and are working hard to hook it up to something which isn’t what it usually is connected to, to the point where people who generally have complaints about “non-native UIs” (hello) sit back and say “actually this is not too terrible” I think you have to give it to them.

Edit: I thought more about it and I think I was misunderstanding where this conversation was going. I do care very much about native controls being more than looking native. The thing is that in the web really the only thing exposed is how the control looks because all the platform behaviors have to be stripped out: for example, on one OS a native control with the word “OK” inside of it may be implicitly activatable via the pressing enter on the keyboard, but such an interaction is undesirable on the web because a button should have the lowest common denominator of behaviors. There really is no room for much more than the actual UI of a control to show platform conventions and so when I call things native in this context I mean that they are native as they can be used in a webpage. Plus more complex interactions, which is often where such “native” frameworks go wrong, are just not a thing on the web so I am using ignoring them while you are not.

I guess you can use the word "native" to mean whatever you want, but I assure that (as a former Mozilla developer) if you claim "Firefox uses native controls" (because internally it calls into platform APIs for some rendering sometimes), people are going to get mad at you.

Yup, I know both you a Patrick work(ed) on this stuff, hence why I will from this point on stop claiming things about Firefox as I have not done more than glance at the file you linked. However, as someone who is fairly familiar with WebKit and even worked on it for a short period, and as someone who happens to be a person who gets mad at others at claiming that they are designing “native” UIs: I think calling what Safari does as “native” is a better description than saying it is not. (To give you an idea of where I tend to draw the line: Flutter is not native. Qt is not native. React Native uses native controls, as does wxWidgets.) I think of you asked a random software engineer how they thought web controls were implemented they’d guess that they were drawn and implemented from scratch in the browser, and some browsers (like Chrome) actually do this. What Safari does isn’t drawing a rectangle on a screen using Quartz: it’s actually pulling the class that defines the UI of a button from Cocoa and putting it on the screen, making sure it stays consistent with the DOM. There are actual AppKit engineers working on this and they call these native controls. Safari sometimes needs to disable or patch around bugs in them. It’s basically as close as you could possibly get while still being able to use one of these in a webpage.

Edit: as I mentioned in another comment, what I’ve really been trying to say isn’t that they’re as native as the web will let them be, and that happens to allow them to use a fair bit of platform-specific code if they would like. I think the things you are trying to bring up are just a consequence of the web not being a native platform.

You can't tell by looking at the controls whether Safari is using the native control implementation (it isn't). All you can tell is that the Webkit implementation looks like and acts like the native implementation.

I can't tell by looking at them, which is why I am speaking from experience that they are actually using native controls :)

> Browsers can't use the OS control implementations, because the demands of DOM/CSS simply can't be handled by those native implementations. [...] It is very hard to get 100% right, which is why no browser does.

This is not correct. In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this. For example, <select> elements in Chrome and Safari are native elements (albeit Win32 versions in the former on Windows).

Chrome and Safari are absolutely not using the actual native control implementation. E.g. on Windows Chrome is not jamming a combobox HWND into its browser window.

> In instances where CSS doesn't affect the styling of the control, the browser can use native controls. As far as I know, every browser _except_ Firefox does this.

This is not true. It's not just the styling of the control itself that makes it infeasible to just stick an NSButton inside the browser's NSView; it's about the way a control interacts with everything else on the page.

Source: I work on browser graphics.

Unstyled buttons look like Aero. CSS-styled buttons (custom color, border appearance) look like 9x.

It seems that it's faster on every website I use except Gmail, Google Voice, and Youtube. I wonder whether Google is using some sort of Chrome-specific javascript to make those sites run faster in their own browser?

I'm not sure if this is still the case, but Youtube used to use WebComponents v0 which has to be emulated in JS in non-Webkit browsers, since only Google ever implemented v0, while everyone else agreed it required a bit more work, and other engines run v1 instead, which is not compatible.

Youtube was updated to the v1 quite some time ago with a fresh Polymer version

>Polymer.version

3.4.0

Polymer uses v1 WCs since Polymer v2

Thanks! I had no idea how to check if it was still the case.

The main YouTube site seems to still be lousy in Firefox. Buttons that should open dropdowns (e.g. the top right corner user icon and notifications icon) don’t. If I want to actually see notifications, I need to tack ?disable_polymer=1 onto the URL and experience the ancient site!

YouTube Studio doesn’t suffer from these problems.

Hmm, seems to work fine for me.

I have no idea when it stopped working, because I scarcely ever used the affected buttons until very recently—I have a vague feeling it might have worked three or four years ago, but in the last couple of months it’s definitely not been working for me.

uBlock Origin is the only extension that I have that could feasibly alter anything, and all it’s doing is blocking googleads.g.doubleclick.net. Nothing of interest shows up in the dev tools. 99.9% sure the bug is with YouTube, though in what particular way I cannot guess.

I can confirm that uBlock Origin blocks the notification dropdown on Firefox. Does the dropdown get served by the ads server?

Ah hah! Figured it out: some cosmetic filter is killing the dropdowns. Unfortunately the effecting rule is not discernable in the dev tools, so figuring out which rule is at fault is tricky and slow.

Found which one, too: it was a rule of my own that I added almost a year ago to kill off some of the annoying cards they pop up at the ends of many videos, which hide the video content; turns out my rule was just a touch too broad for how they do things.

Mea culpa.

Aha! In my case it was a filter I added to block the "Upgrade to YouTube Red" banner that kept coming up even after I clicked "No thanks".

I use uBlock (and some others) and have no problems clicking either buttons

It doesn't exactly need to be Chrome-specific; every browser/JS engine will have slightly different performance on different workloads, so Google just has to lean heavily on things that are golden-path for Chrome. They could even do this accidentally/nonmaliciously just by mostly testing on Chrome and not testing performance on other browsers.

> They could even do this accidentally/nonmaliciously

Designing a development process that naturally achieves a malicious outcome is just as bad as actively making malicious decisions: https://www.zdnet.com/article/former-mozilla-exec-google-has...

Wouldn't it rather be "Maintaining and not fixing" rather than "Designing"?

Google is perfectly allowed to make mistakes or forget something. The criticism is that this is a repeated behavior, as if they decided that it is never going to be a priority.

Judging by how they treat those websites on Android on Firefox vs Chrome I am most definitely certain they are doing that.

Reminds me of the Chappelle Show skit about Kinko's:

https://www.youtube.com/watch?v=zR7LOtMix9w&t=155

"A lot of people ask, 'Why? Why treat [other browsers] this way?'"

"Why? 'cause f*ck 'em, that's why."

I can corroborate this. YouTube especially.

Does anyone have any hard numbers to validate this? Or are we just random outliers?

More anecdata: every Google product I use (GMail, Google Drive/Docs, YouTube) either works slower or eventually develops memory leaks on Firefox.

Nothing specifically malicious. Since Chrome is default browser at Google, it’s used as default development and profiling browser, and then it’s ported to and tested on other browsers, obviously not as much.

Concerning form input styling, many of the responses that have been made before this time are broadly technically incorrect or insufficient (roca’s comments are excellent, as a developer in this very space), and no one’s mentioned that work is actively happening in this space.

On Windows, Firefox currently uses Windows APIs to draw the form controls, scrollbars, &c. where possible, and imitates the style in the places that there is no native API for it.

https://bugzilla.mozilla.org/show_bug.cgi?id=1381938 introduced a new style, available behind the widget.disable-native-theme-for-content pref. I’ve been using it for the last three months and reporting various bugs and problems. https://bugzilla.mozilla.org/show_bug.cgi?id=1615105 is tracking the remaining work before it can be turned on by default.

My opinion: the new control styles are… fine, I guess; but they could do with some not-flatness (especially for buttons), and increases in size and padding are seriously problematic on many existing sites.

My LOD 3D models still take ~10ms per batch to load from binary file in Firefox, whereas Chrome needs ~1ms per batch. Mostly because of DataView but Mozilla recently assigned someone to work on it so I'm hopefull for the future.

I recently switched to Firefox after being a Chrome user for the most part of my life. In the past I couldn't switch to Firefox due to a lack of alternatives for the extensions I use on Chrome (particularly Google Dictionary) but I recently use Firefox again and decided that the performance difference is worth the change. I still miss the extension options I had sometimes but I have to admit that my overall browsing experience is markedly improved on Firefox. Glad to see that my anecdotal browsing experience is backed by benchmark.

Would love to see how Safari handles your benchmark! I find it pretty fast, but maybe that's just bias because it treats my battery nice.

I ran three trials of each on a min spec 2019 MacBook Pro 16". All numbers are ms rounded to the nearest integer, all browsers are latest stable. I also loaded the page with dev tools closed since that affected times.

Browser: (trial 1 prep, trial 1 chart), (trial 2 prep, trial 2 chart), (trial 3 prep, trial 3 chart)

Chrome: (649, 347), (638, 343), (618, 358)

Firefox: (353, 307), (358, 307), (361, 308)

Safari: (281, 264), (287, 258), (309, 262)

Similar experience. Beating WebKit on macOS in rendering performance or energy use is very hard for both Chrome and Firefox (and the clones).

Very interesting. Thanks a lot! Firefox did really well, that’s cool to see.

there's an artificial 500ms delay in there between fake data gen and chart drawing so it's easier for me to isolate the two in the perf timeline :)

> Would love to see how Safari handles your benchmark!

i don't have access to a Mac, so you won't get this from me!

Fair enough! Thanks anyway, though.

Firefox uses Direct2d on windows, while Chrome will just use Skia.

Reply on news.ycombinator.com