Lol. On first glance I read "Fallout 76".
Firefox 76
201–210 of 274 posts
Re: Firefox 76
#202Earlier quoted context omitted.
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 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.
Re: Firefox 76
#203Earlier quoted context omitted.
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 . (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 respective…
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.
Re: Firefox 76
#204Earlier quoted context omitted.
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 . (Interestingly, Safari will outright ignore font sizes it cannot draw a native control for…)
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 :)
Re: Firefox 76
#205Earlier quoted context omitted.
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?
It was originally ported for and is still used in iTunes.
Re: Firefox 76
#206i 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 stylin…
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?
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.
Re: Firefox 76
#207i 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 stylin…
[dead]
Re: Firefox 76
#208Earlier quoted context omitted.
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
Re: Firefox 76
#209Earlier quoted context omitted.
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 respective…
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.
Re: Firefox 76
#210i 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 stylin…
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.