There are 2 things I miss from switching to FF: Right click on a picture -> search google for image Right click -> Translate page Everything else seems smooth enough.
Search By Image: https://addons.mozilla.org/en-US/android/addon/search_by_ima... Translate Now: https://addons.mozilla.org/en-US/android/addon/translate-now...
All the translate addons take you to the Google translate variant. It does not help at all especially when buying stuff from websites for example. I prefer the on-spot translation of chrome. The user experience is very bad with these translate addons.
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.
iTunes uses CoreFoundation but it kinda barely uses AppKit even on macOS.
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 wor…
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 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.
I disabled it in the first 15 minutes. I just hope they don't remove the disable recipe. (about:config browser.urlbar.update1 -> false)
Honestly after getting used to it I like the change. Why? Because before it was often not easy to see if the input focus was on the address bar or somewhere else, and often I'd start typing and the input land somewhere I didn't expect. Now at least it's very clear, although I agree they could have done it better.
...am I seeing the same thing as others? I'm using up-to-date Firefox, but I toggled the about:config flag to get the old address bar, figuring I may as well use it while I can. Here is what the address bar looks like for me: Focused: https://i.ibb.co/TWDw9WL/Screen-Shot-2020-05-05-at-5-30-57-P... Unfocused: https://i.ibb.co/QHd0SBm/Screen-Shot-2020-05-05-at-5-31-01-P... Do you not see the blue focus outline? It's pr…
On windows they had a drop shadow effect outside the address bar which is less pronounced now.
I love Firefox and use it as my primary browser for years but few things which annoy me: - Sending tabs between devices does not work. It sometimes arrives 12 hours!!! later - Google Cloud Console has some UI issues on Firefox - Twitter input field behaves extremely strangely when you enter an emoji and try to edit text afterwards - I don’t understand why some html elements have a different appearance and default css…
Firefox made a huge mistake following in Chrome's trail with the version numbering scheme. I just don't care about Firefox 76, is it a big change? Is there some new feature I would want to try? Who knows, I'm sure Firefox 77 will be out soon though!
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…
What’s the advantage behind a more complex scheme? It doesn’t seem to add anything. The current system just notes the specific release in a series of releases.
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 utili…
> all the programs running as user have read/write access to each other.
On many linux distributions this is not the case as yama ptrace_scope is enabled by default.
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 stylin…
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.
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.
> 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, elements in…
> 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.