firefox also removes 'www' and 'https' in drop-down search results from the address bar[0]. it's a subtle change, but worth knowing. 'http' urls remain in long form apparently (haven't installed yet to check it out).
edit: min(), max(), and clamp() for css looks useful too.
edit 2: honoring 'nosniff' on mime types on page load is neat too [1]
Fenix is also now stripping https:// and https://www. from the address bar, which I strongly approve of as it has none of the downsides that doing that would have on desktop (OK, OK, so www. stripping can be theoretically significant), and I have a not-huge device so that that was taking up around half of the space allotted to text. Now if only I could do away with the padlock (only show it when it’s problematic, not all the time) and shrink the remaining badge much smaller. And/or if you could scroll the text horizontally like you could in Firefox for Android.
Except in Chrome, say I’m on https://www.google.com/chrome/, which is shown as google.com/chrome/. Now for one reason or another I want to copy only part of the address, say only the domain name. So I grab “google.com” with my mouse and command+c to copy it. Congratulations, I just copied https://www.google.com, although I explicitly selected only the “google.com” part. I can understand the behavior if I was copying the entire URL.
Now, I’m not sure how this is handled in the mobile Firefox Preview, but thankfully on desktop they only dim https://[www.].
(Btw, it seems a sibling somehow has the exact opposite gripe.)
I wouldn't have a problem with it, if not for my experience with Chrome letting you copy addresses out of the address bar without the https://www. I don't think it's supposed to happen, it doesn't happen every time, but I've had it happen.
This is obnoxious because when I then paste that link into something else, like an email, IRC or HN comment, it generally won't get automatically 'linkified.'
"On Linux, the behavior when clicking on the Address Bar and the Search Bar now matches other desktop platforms" - yay, I have found it annoying that you need to double-click in order to select all and start searching
When this change was made in FF Nightly I was annoyed enough to find out why it happened and file a bug report about the regression (https://bugzilla.mozilla.org/show_bug.cgi?id=1619801, and a dupe at https://bugzilla.mozilla.org/show_bug.cgi?id=1621570), but apparently it was an intended change. What's annoying is that instead of just changing the default for Linux to be in line with other platforms, the option to not select the URL when clicking was completely removed.
Now I have to click on the URL, wait a second, and then click again to place the cursor instead of selecting all. Especially annoying if you accidentally move your mouse off by a character between the two clicks. This makes me quite mad the few times per day I run into it - the feature is quite useful for changing URLs, which it turns out I do quite often, even though I'm usually not a web developer.
I'm currently compiling Firefox with the patch reverted. EDIT: It worked!!! Compiling took about an hour with an AMD Ryzen 3800x (8x 3.9-4.5 GHz) and NVMe SSD and 32 GB RAM. I'll post a link in a followup comment here with instructions on the simplest way to do this on Arch Linux (uses the build infrastructure already setup to create Arch's regular Firefox package, just modified to also revert the patch which removed this preference). Of course there's no guarantee that this will continue to work in the future as the FF codebase is updated.
> Still doesn't help for adding something onto the end
If I'm going to need to type anyway, I'd rather do that with the keyboard than the mouse: Ctrl-L End /xyz or Ctrl-L Right /xyz feels much faster to me than "move mouse to end of address bar, click, /xyz".
(I absolutely understand that relearning/retaining muscle memory takes time and feels frustrating, though.)
I do the same thing, but with Alt-D. I thought it was strange that there are duplicate hotkeys for the function, but looking at the shortcuts page shows that's not uncommon. It seems F6 does the same thing, but I can't remember the last time I used an F-key.
Thanks for filing and discussing it. It's sad that this change landed from issue initially specified as "browser.urlbar.clickSelectsAll should default to true" but actually ended up as "let's toss this option away completely and be like every other average browser". :(
If you are wondering why this discrepancy in behavior between platforms: This default behavior was initially changed to prevent a 16-years old bug in SeaMonkey, which was already fixed in Firefox since 2007. See following issues for more details:
Just to avoid any confusion, I have nothing to do with the change of behavior in Firefox 75. And the « fix » was only about changing the default behavior with new prefs values (the real fix was done in Firefox around 2007 but for some reason the default behavior was never reverted until now).
So is this the reason for `browser.urlbar.clickSelectsAll=false` in about:config to cease to work (on Windows)? Not fortunate for me; I liked this option to NOT have it selected after single click. Triple click is for this kind of selection in my old habits.
Also when I'm clicking something that looks like text field (what Awesome Bar looks after all), my primary intention is to type there something. Even if my my intention was to select some text and I expected it, I don't expect it to open extra drop down with "top pages" (like it now does): that's what buttons usually do and what the "⌵" button in Awesome Bar in previous version did. Now click does not one, not two, but three thinks simultaneously.
Is there some pref that tells Firefox to not show those suggested options immediately after URL bar text field's focus?
I press ctrl+L to start typing an address (ctrl+K to search). You're already going to use the keyboard to type so it's easier than clicking. I prefer clicking to do the normal, expected behaviour.
I try to use the keyboard a lot but for some reason I often "click" the address bar when searching and/or changing in the urls so I this was a caveat for me actually.
"Experimental support for using client certificates from the OS certificate store can be enabled on macOS by setting the preference security.osclientcerts.autoload to true."
This allows Firefox to work with my company's BeyondCorp implementation. I was forced to use Chrome before.
Enterprise root certs are different from client certs even if some (perhaps many or most) client certs were signed by an enterprise root. A client cert is about providing identity information/proofs (instead of or in addition to traditional credentials). I hope mozilla isn't conflating the two though I can see how they might decide that turning on one thing gets you the other as well.
That's possible, but the certs expire very quickly and they only offer access to a tiny subset of resources. You'd be constantly exporting & importing certs.
And there are some minimal improvements to "Install Website as App": now app is not grouped with Firefox icon on Windows, displays correct icon. Little steps towards full PWA support.
The address bar looks horrible when selected [0], it outgrows its container and invades the space of tabs. I thought it was a bug at first, but it's probably intentional. is there a way to go back to the normal address bar?
It is similar on Mac OS. Seems like a reasonable method to shift focus. Doesn’t break things but it different so might need a little settle time to get used to.
Wait, Am I the only one to notice right away that FF FINALLY added a "Default Zoom" option to its settings? Or has this been there before recently and I've missed it? If this is new then THANKS 1000x.
For YEARS this was my main annoyance with FF of not having a general zoom added to all webpages and was the only browser that didn't. FF would remember your set zoom for sites (provided you didn't check "site preferences" in clearing history) but it just became so tedious to have to manually zoom pages you haven't visited before.I even tried to resort to some clumsy add-ons that tried to makeup for lack of system wide zoom
{FF as default browser user since Opera died and went to being chrome. Although I do test others out once in while like Brave/Vivaldi/EdgeChrome I'm still loyal}
No, you weren't really missing anything, default zoom is very recent. I don't remember which version it was, but it was within the last 3. It's a big deal for accessibility.
There's no mention of any of the promised Wayland improvements (which I'd been looking forward to).
It's a bit unclear if it hasn't made it to the final release, or if it's just a matter of the Linux userbase being too small for them to announce Linux-specific changes.
According to https://wiki.archlinux.org/index.php/Firefox#Wayland, if you want to see whether you're using the Wayland version of Firefox, go to about:support and look next to "Window Protocol". Wayland can be enabled at runtime using an environment variable: `MOZ_ENABLE_WAYLAND=1 firefox`.
I just updated to Firefox 75 and it's still using x11. If I opt in to using Wayland, it works, but annoyingly I can't detach a tab by dragging it off of the window. So it looks like Wayland support is not quite there yet.
XPath search is a good one. I've used to scrape some data from the sites and missing search by XPath forced me to use chromium derivatives. Great to see this feature coming.
Hardware video accelleration on Linux with Wayland!
I've tested it on Youtube, it works alright, definitely less CPU usage, however on twitch.tv I still get some graphical glitches.
Once you start typing the same icons should show up again. You can click on them to perform just that search with the selected search engine, or right click on it to make it the default.
The very worst I've seen is in Krita (maybe they've changed it) where to make a new brush you had to select the name field of an existing brush and edit it, and only then would the button for "Save a Copy as a New Brush" or whatever appear. Good luck hunting for the "New Brush" button, you're not going to find it.
Now it is recommended to use width and height attributes on img elements. It will help to prevent viewport jumping and will support responsive aspect ratio resizing.
https://www.youtube.com/watch?v=4-d_SoCHeWE
WordPress does this by default and that’s the most common platform to date. I’d dare to say that most websites have those attributes, but most SPAs don’t, because that’s too hard.
Viewport jumping is the scourge of web browsing; if some browser deployed some kind of advanced heuristic to try and get rid of it completely that alone might get me to switch.
Nearly all image formats have image dimensions in their header, so a hundred-byte prefetch per image should give the browser the image size IF it's not specified in the html or css.
Both Firefox and Chrome have implementations of scroll anchoring which is intended to fix this. The implementations are different and neither is perfect, but in a lot of cases they do help with jumping.
I think the biggest cause of this is not regular site images but dynamic ads that come in after the main page loads and never include size information. It’s even worse when the ads change and have a different size that causes the layout to shift while you’re reading an article.
But both Firefox and Chrome have implemented this: when your img tag contains both height and width attributes, the browsers use those to calculate the aspect ratio, and use those to reserve the correct amount of space when rendering the page.
They should fix looking up for things such as "clipboard.js" attempting to look up the domain and giving not found page. Chrome is smarter in this regard.
That is one way to look at it. Personally, I don't regularly use any operating system that has such a preference. To me, FF supports dark mode, although not certain operating systems' implementations.
That preference exists on macOS, Windows, iOS, and Android, so it's not an unusual expectation for users to have. Supporting system dark mode means that you can do things like have all applications automatically switch themes based on the time of day.
Revising my opinion; Firefox dev tools has a dark theme, but it doesn't support dark mode.
I definitely agree if you compare it to MS Edge. However, it appears you are being downvoted for disagreeing with the Mozillian crowd in this thread by critiquing their beloved Firefox which is somewhat seen as treasonous.
Try to play nice with the Mozillians here by praising their saviour Rust on each Firefox release since they will hunt us down if we complain about crashes, unsafety or any other bugs in Linux.
I have to agree here. If VSCode seems to be a widely accepted editor on HN using Electron, then I can't wait to see what Microsoft has done with MS Edge which so far is a breath of fresh air.
edit: min(), max(), and clamp() for css looks useful too.
edit 2: honoring 'nosniff' on mime types on page load is neat too [1]
[0] https://www.ghacks.net/2020/02/28/firefox-75-address-bar-res...
[1] https://blog.mozilla.org/security/2020/04/07/firefox-75-will...