Firefox 75: Ambitions for April(hacks.mozilla.org)
hacks.mozilla.org
Firefox 75: Ambitions for April
https://hacks.mozilla.org/2020/04/firefox-75-ambitions-for-april/
96 comments
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.)
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.)
> it seems a sibling somehow has the exact opposite gripe
If you don't have two users complaining about the exact same issue but in opposite directions, your feedback channels aren't working. ;)
If you don't have two users complaining about the exact same issue but in opposite directions, your feedback channels aren't working. ;)
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.'
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.
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.
If you just care about changing part of the URL, you can click and drag to highlight and then type to replace.
Dang, I never thought of that. Thanks!
Still doesn't help for adding something onto the end, but good enough for 90% of cases.
Still doesn't help for adding something onto the end, but good enough for 90% of cases.
> 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.)
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". :(
Yey! This is a fun one, I fixed it in Cliqz (a browser based on Firefox) a while ago: https://github.com/cliqz-oss/browser-f/pull/912#issue-195908...
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:
* https://bugzilla.mozilla.org/show_bug.cgi?id=190615
* https://bugzilla.mozilla.org/show_bug.cgi?id=611162
Inertia I guess... happy to see this fixed upstream!
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:
* https://bugzilla.mozilla.org/show_bug.cgi?id=190615
* https://bugzilla.mozilla.org/show_bug.cgi?id=611162
Inertia I guess... happy to see this fixed upstream!
Great work! Nice with the background to the annoyance.
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?
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.
As a pentester I love this fix. Like when testing simple payloads on GET params (and switching back and forth between host MacOS and Virtual Linux).
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.
A big one for me (covered in the release notes):
"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.
"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.
Awesome. Any word on whether this also applies to Windows? (Asking for a company-issued notebook.)
On Windows, you should be able to set `security.enterprise_roots.enabled` to true. Might have to restart Firefox for it to recognize.
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.
Could you not just copy the cert from keychain to firefox’s cert store?
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.
Built-in support for lazy image loading is pretty nice! No more annoying JS-based hacks to get it to work.
Do all the other popular browsers, like Google Chrome, Microsoft Edge (the new one) and Brave, also support this?
It looks like the Blink based browsers do. https://caniuse.com/#feat=loading-lazy-attr
They mention in the post that Chrome has implemented lazy loading for both images and iframes, suggesting it's also in Edge and Brave.
[deleted]
Still waiting for support on Safari and a few mobile browsers.
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.
Just got the update on Ubuntu.
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?
[0] https://imagehost.imageupload.net/2020/04/08/Screenshot-from...
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?
[0] https://imagehost.imageupload.net/2020/04/08/Screenshot-from...
Two things I am looking forward to:
* Lazy loading images without JavaScript
* Static fields in JavaScript classes - I wanted to use this the other day and was disappointed that FF didn't support static fields yet.
* Lazy loading images without JavaScript
* Static fields in JavaScript classes - I wanted to use this the other day and was disappointed that FF didn't support static fields yet.
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}
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.
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 Phoronix it's in:
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...
plan to be on ff 76
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-...
Although probably not enabled by default.
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.
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.
I second this, since I switched to wayland, I noticed many weird graphical issues with Firefox, hoping this release will fix them.
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.
[deleted]
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.
How do I change search engine from search bar? Before update there were icons with my saved search engines, but now they are nowhere to be seen.
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.
I hate this kind of UI.
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.
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.
Will lazy-loading images avoid viewport jumping? Because that's a constant headache on mobile Safari.
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
That's been recommended since about 1993. That doesn't mean more than 10% of sites have ever actually followed the guideline.
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.
If you specify both a width and height, it's not going to be very responsive.
The attributes are overridden by CSS. You should have:
Kinda ridiculous that we had to wait 8 years of “responsive design” before they realized that this was always supposed to happen.
max-width: 100%;
height: auto;
Kinda ridiculous that we had to wait 8 years of “responsive design” before they realized that this was always supposed to happen.
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.
I remembered hearing about Chrome doing it a while ago [1] but I still personally experience it fairly often.
1: https://blog.google/products/chrome/taking-aim-annoying-page...
1: https://blog.google/products/chrome/taking-aim-annoying-page...
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.
Nope, lazy loading neither helps nor hurts that issue. Devs can fix that by ensuring image elements have a defined size.
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.
I don't think so.
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.
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.
Its being worked on: https://bugzilla.mozilla.org/show_bug.cgi?id=1080682
Closed now!
It would be great if the inspector supported dark mode.
It has for a while. https://developer.mozilla.org/en-US/docs/Tools/Settings
Kinda. It has a dark mode, but it doesn't seem to pick up the system preference.
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.
Revising my opinion; Firefox dev tools has a dark theme, but it doesn't support dark mode.
If only dark mode on macOS also included the context menus.
ah live console eval as comment, such a bliss
Hopefully this fixes Firefox 74. First time in years I can say that I've had stability problems, frequent crashes, etc.
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'll go first: 𝔓𝔯𝔞𝔦𝔰𝔢 ℜ𝔳𝔰𝔱 MMXX
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'll go first: 𝔓𝔯𝔞𝔦𝔰𝔢 ℜ𝔳𝔰𝔱 MMXX
> evnt breakpoints
Typo in the first paragraph.
Typo in the first paragraph.
[deleted]
World runs on mobile, Mozilla focuses of desktop.
Firefox Mobile also has a lot of improvements coming up. The previews are actually quite amazing
Most web developers (which this piece is presumably of interest to) do their work on desktop.
On desktop (laptop truly) here
Nice to see Mozilla keeping up. Don't really have much reason personally to use Firefox nowadays though due to the new Microsoft Edge being so good.
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.
Time to go where the 'real' users are.
Time to go where the 'real' users are.
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...