Live data from Hacker News

Firefox 76

mozilla.org

191–200 of 274 posts

Re: Firefox 76

#191
post #182

Earlier quoted context omitted.

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

Re: Firefox 76

#192

Thank you to the Firefox team, this seems like a really nice release. I am very happy about the "If you don’t have a master password set up for Firefox, Windows and macOS now requires a login to your operating system account before showing your saved passwords." change. It might seem like a small change, but it's one of those friction points (another password to remember!) that will lead to (hopefully) more people us…

Personally, I don't like operating systems that train users to enter login credentials while using the system as this increases the chance of someone capturing those credentials via spoofing. I used to think Firefox trying to protect the entered passwords made some sense, but I've been convinced it isn't really such a good idea. Better would be a full profile being protected (with all files encrypted), or just rely o…

If an adversary can get user access, they generally are able to also get root access (via social engineering or a local vulnerability). They'd also be able to read the memory of the web browser, or file contents. This is because on an average desktop, all the programs running as user have read/write access to each other.

On mobile OSes, capabilities are enabled by default. Even Symbian already had such. OpenBSD utilizes pledge to minimize impact.

Re: Firefox 76

#193

> The shadow around the address bar field is reduced in width when a new tab is opened; I mean, at least they're trying, I guess. Still seems to me like lipstick on a pig. I'm still trying to figure out what UX problem the expanding bar was intended to address.

Yeah as somebody that uses the bookmarks bar, this is just maddening. First I go to about:config on my personal profile, great. But I have a work profile, and once again I have to turn it off. Dev Edition gets the update, gotta turn it off there. Login to desktop at work. Repeat all 3 of those. Oh, work laptop also needs all 3 to get updated. Then I move to my MacBook, gotta turn it off again. Power up my old Dell XPS13, god damn it I have to turn it off again...

Re: Firefox 76

#194
post #135

Earlier quoted context omitted.

I want to figure out who to talk to on both Firefox and Chrome sides to beg that they adopt a scheme like YYYY.MM.minor for their version numbering. I believe that would be superior for basically everyone —web developers, users, &c. (In the case of Firefox, it works especially well since they’re releasing approximately monthly now. I could imagine people on Chrome puzzling over why some month numbers got skipped—not…

Releases are almost always date-based, but once in a while a release is delayed. I guess that's a bit easier if the release number is not a date.

There's also the fact that Firefox is now on a 4 weeks release cycle, which means there will be months with two releases. (and that's ignoring chemspill releases)

Re: Firefox 76

#195
post #3

Anybody using Firefox password manager that can comment on it? Is it considered safe enough? Are the passwords stored remotely if you have multi-device profiles? Edit: I asked because I see that some of the updats are related.

I believe you can host your own instance of the back end portion if you wish:

https://github.com/mozilla/fxa

Re: Firefox 76

#196
post #135

Earlier quoted context omitted.

I want to figure out who to talk to on both Firefox and Chrome sides to beg that they adopt a scheme like YYYY.MM.minor for their version numbering. I believe that would be superior for basically everyone —web developers, users, &c. (In the case of Firefox, it works especially well since they’re releasing approximately monthly now. I could imagine people on Chrome puzzling over why some month numbers got skipped—not…

Releases are almost always date-based, but once in a while a release is delayed. I guess that's a bit easier if the release number is not a date.

i mean, whats the problem with the version going up 2 numbers rather than 1?

Re: Firefox 76

#197
post #182

Earlier quoted context omitted.

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

Re: Firefox 76

#198
post #135

Earlier quoted context omitted.

Releases are almost always date-based, but once in a while a release is delayed. I guess that's a bit easier if the release number is not a date.

i mean, whats the problem with the version going up 2 numbers rather than 1?

It's suboptimal to have to change the number of the next release during a release cycle. That would mean, for example, that Firefox Nightly 2020.11 might correspond to a Firefox release 2020.12.

Re: Firefox 76

#199
Hearing good things about firefox performance vs. chrome in this thread, I thought I would have a look at firefox use of rust - I found this informative page which provides a lot of rationale for where rust has been used: https://wiki.mozilla.org/Oxidation

Here is a cut of what was introduced in Firefox 76 (copy&paste)

Integrate fluent-rs, a localization system: bug 1560038 (shipped in Firefox 76)

Why Rust? Performance and memory wins are substantial over previous JS implementation. It brings zero-copy parsing, and memory savvy resolving of localization strings. It also paves the way for migrating the rest of the Fluent APIs away from JS which is required for Fission.

Re: Firefox 76

#200
post #134

Earlier quoted context omitted.

The commenter at the top of this thread wanted to know whether this version of Firefox is a "major release". Using the date doesn't change that.

"Firefox 10-04/20” "Firefox 10-05/20” then " Firefox 11-06/20”. Though deciding what's a "major release" seems like a thankless hassle.

Indeed.

There is no right way to decide what is a major release. Whatever you do, some users will think a major release should have been classed as minor, and vice versa. It's ultimately easier for everyone if you don't make the distinction.

Post reply on HN