Firefox 50.0
mozilla.org
mozilla.org
Finally something that is an actually improved UI feature!
Not some "removed status bar and instead hover its info over text you want to read sometimes" or "moved refresh button to different place than before just to annoy you" or similar thing :)
As well as the alt+tab desktop behaviour
FLST: https://addons.mozilla.org/en-US/firefox/addon/fww-flst/
It just works. Tab switching is instant, no unnecessary preview, and it has never messed up remembering tab order.
Glad to see they are paying more attention to this though.
Thousands of people have requested that feature for Chrome. To this day there hasn't been (or I haven't found) an official answer and the only way to do it is to use an extension, using an alternative keybind as extensions aren't allowed to interact with ctrl-tab.
I feel like ctrl + tab has to move to next tab & ctrl + shift + tab should move to previous tab (cycle if it reaches the end).
I feel like that's more predictable behaviour.
Not to mention you'd need to set the hand from one end of the keyboard to the middle, just to press something you'd otherwise move 1 key.
As I said, it's dumb.
(And then meta-tab is also hanging out there, being simple and ready for an alternative context switch (mostly browser <-> terminal).)
On Atom, I've set ctrl + tab to remap to pane:show-next-item, and ctrl + shift + tab to pane:show-previous-item.
(view your keymap, and see what ctrl + page-up/down is bound to, and then bind it to ctrl + tab /+ shift)
Edit: here are my settings:
'body':
'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'unset!'
'ctrl-shift-tab': 'pane:show-previous-item'
'ctrl-shift-tab ^ctrl': 'unset!'If you only have a few tabs open, it can be useful in conjunction with Ctrl-[1-9], but I am also still strongly in the next/prev tab camp.
I don't use ST, but at least in Atom, I know you can easily override it in your keymap:
'body':
'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'unset!'
'ctrl-shift-tab': 'pane:show-previous-item'
'ctrl-shift-tab ^ctrl': 'unset!'And I love it :-p It is literally the reason (in combination with "open new tab next to current") I use the browser I do (Vivaldi; would consider Opera, but it doesn't/didn't do "open new tab next to current").
To each their own :-)
You can enter "% string" into the location bar, and it will suggest switches to open tabs which contain that string either in their title or URL.
I've been using this little-known location bar feature for a long long time.
However, I am unable to use it through the keyboard. The undocumented C-S-l seems to trigger a search over there. But there is no way of navigating to a matching tab without the mouse. Any tips?
[1] https://github.com/bwinton/TabCenter/issues/498#issuecomment...
I'm joking of course that I think to desire otherwise is insane. Except I'm not. Or am I? :)
Hence, alt was just hanging out being useless :-p (I'm like 95% terminal or browser, so it's a great use of alt to me :-) )
Amusingly, last time I used OSX or Windows properly, I got super grumpy about the fact "(alt|mac)-tab" seemed amazingly inconsistent - I think cause I'd try and switch consistently between two windows, and got surprising-seeming results... I somewhat think I had gremlins :-p
(As I wrote this I actually did a few ctrl-tabs and a few alt-tabs... I hadn't quite realise I used both as often/evenly...)
(It is literally the reason I will not be leaving Firefox after this Ctrl-Tab moves to most recently used tab abomination :))
{ "keys": ["ctrl+tab"], "command": "next_view" }, { "keys": ["ctrl+shift+tab"], "command": "prev_view" }
Also Preferences -> Key Bindings works too but I'd encourage everyone to get used to the command palette for all sorts of commands like Set Syntax and Package Control
Usually when programming, the most relevant are the last source files I viewed, e.g. a source file and its header file. I love ctrl+tab switching between most recent files this way.
Same in a webbrowser with related articles. Don't see a use of a next/prev in the list tab shortcut myself, it's not like tabs are ever in some particular order for me :)
If I want to go to specific file, I'd just Ctrl+P and type in the filename.
Using Ctrl+PageUp/Down to scroll through all open tabs is predictable but kinda useless since I have 20+ tabs opened after a while.
If I want to switch between 2 tabs quickly - I set them side by side and it solves the problem for me.
Only reason I'm mentioning it here is that it looks like the repo is dead.
https://developer.mozilla.org/en-US/Firefox/Releases/50#Chan...
Granted, it's done by mimicking Webkit APIs, but that has the advantage that existing sites work without changes.
Uploading individual files in a directory = was possible
Uploading an entire directory (eg: a folder to a cloud storage service) = was not possible
Am I missing something or was that right?
Example of error: http://superuser.com/questions/909112/does-firefox-support-f...
Thanks for the response!
For example the RTFD format. This is a rich text document with embedded images. It is actually implemented as a folder containing a RTF file and the images. In the Mac GUI however it appears to be a regular file.
Attempting to upload it on the web would fail without the ability to upload directories. This may well explain why WebKit (being from Apple) was the first to implement this. I bet they needed it for their iCloud web app versions of Pages, Keynote etc.
That's ... not a bad thing. Chrome creating nonstandard APIs (IIRC this was for Drive?) on its own is a bad thing. Coming together and speccing (https://wicg.github.io/directory-upload/proposal.html) the API is a good thing. They seem to have specced more or less what Webkit had already implemented (plus some promise based stuff), but usually when a nonstandard API has been out there long enough it's best to build your standardized version on top of it instead of having two APIs for it. This is a common practice. This isn't "mimicking".
The problem is that the WHATWG always just standardizes "whatever Chrome does".
This leads to the HTML living standard actually being just like Office Open XML, with one entity controlling all of it.
So it's not a terribly bad thing, unless other people's standards are just being ignored
It's actually an unfair advantage.
"Oh, let's standardize what Chrome already has implemented and Google is using". This immediately sets Firefox behind the new "standard", and website that don't work on FF technically "follow current standards".
It really ... doesn't. When the situation has arisen that Chrome has implemented an API for long enough for it to become entrenched in the web, it then discusses standardizing it (see also: https://compat.spec.whatwg.org/). But it's not blindly following Chrome, it's only in these special cases.
I've recently been involved in a couple of issues where browsers disagree with each other and/or the spec. Each time there's a discussion, and the best version of the behavior is chosen and worked into the spec. This best version is not always the Chrome version.
Unfortunately it is very slow compared to Tree Style Tabs if you have a considerable amount of tabs open (even using extensions like auto-unload, it is very very slow). Hope it gets fixed because I would _love_ a built-in vertical tab feature.
However, past a number of tabs (enough to fill the "tab bar" vertically), it doesn't show thumbnails, maybe that's the difference?
Still using Tree style tabs for their sub tabs feature which helps keeping things organised for me.
Container tabs are (IMHO) better than Chrome profiles, because they don't require one to have a separate window just to open a single site.
While everything still happens within a single profile, sites in different containers get different storage (cookies, localStorage, IndexedDB, etc.) and cannot see each other.
I've been using a combination of NoScript,Self-destruction coockies,ublock and a personal vimperator script to wipe out all that nasty stuff when I close the window.
https://github.com/liloman/dotfiles/blob/master/vimperator/....
https://github.com/liloman/dotfiles/blob/master/Scripts/Scri...
By the way firefox is pretty nasty by default and you must do a lot of hard work to evade tracking, in special by google:
https://github.com/liloman/dotfiles/blob/master/vimperator/....
Of course you must use custom fonts if you don't want to be tracked by google for every single webpage you enter.
I think I will play with containers for firefox when I try firefox 50. Something like a new container for every tab, I reckon It must be pretty easy with vimperator(or whatever plugin you like) to make .
Put your vimperator/penta/vimium/X to work for you. :)
It seems archives (such as .bz2, .gz) are treated as executable files. What is the reason for that? https://hg.mozilla.org/mozilla-central/file/054d4856cea6/too...
Took them bloody long enough. Now if only i was not stuck on ESR because GTK3...
Not only I haven't had any issues with it so far, it even looks better than Arch's official package (that's built with gtk3).
The issues have been present with gtk >= 3.20, and they should be fixed with release 50 and 51:
What's the issue with GTK3?
https://bugzilla.gnome.org/show_bug.cgi?id=771708
Firefox GTK3 has regressions too, for instance the bookmark manager not remembering where you were last which works with Firefox ESR (GTK2).
https://bugzilla.mozilla.org/show_bug.cgi?id=1267863
Also GTK3's file dialog is subjectively a huge regression, but others may prefer it, just like Apple's finder changed over time. I still haven't figured out how dconf and gconf work with GTK3, not using GNOME3 as a desktop.
There are more issues with GTK3 but these are the most visible for those of us who don't use GTK3 regularly as part of GNOME3 and have been forced to use it via Firefox. The way I read the GTK3 bugreport it seems like the devs don't test GTK3 outside GNOME3 and hence do not consider it a priority. That one dev has been stressing that a compositor is needed and multiple answers by the reporter that they're using a compositor seem to be missed during reading on the other side. It's a weird exchange. I'm with the reporter. If GTK3 is not supposed to or not tested outside GNOME3, then this should be communicated so that everyone can make an informed decision to use something else or revive the Firefox Qt toolkit code.
I'd be the first to build and use a Firefox where the Qt port was updated and made to work but GTK is the GUI toolkit used by Firefox outside Android, macOS and Windows. That said, GTK2 was and still is very good at what it does. It just works but doesn't support Wayland.
I cannot move to Wayland anyway until xterm or rxvt-unicode are ported since XWayland integration is still imperfect. Like they wrote in the bug report, while GTK2 doesn't have a Wayland backend, GTK3's backend isn't really production quality either with dialogs sometimes opting to zoom out rather than scale out or general stability issues. If you try to start Firefox under Wayland by telling GDK to use Wayland, it just crashes on startup.
If it's that easy, you can probably find some third party that compiles and offers it. I'm not sure why you think Firefox needs to do it themselves.
Somebody requested this and the reality has been ignored so far: https://bugzilla.mozilla.org/show_bug.cgi?id=1268234
If you are on Linux and your distribution provides Firefox, this is a complaint to be leveled at your distribution, not Mozilla (who apparently already makes it easy to build the variant). I'm not sure how we got to a position where people feel justified in criticizing a company providing an open source product that's updated often and provides umpteen different binaries for different platforms and different build for those platforms for not building one more special configuration for what it likely a very small group of people, who can easily do so for themselves.
Why do we use Mozilla binaries of Firefox on linux distro where there's Firefox builds in the package repository? Many reasons:
1. fast access to security fixes
2. access to EMEfree builds
3. access to different channels
While it is easy to build with cairo-gtk2 as the backend, that code path, as I wrote in a sibling comment, reliably crashes for me anytime I try to do File-Open. I'll try to find out if that AUR recipe or Gentoo ebuild do something different that makes it stable, but the fact remains that GTK2 is about to be unsupported by Mozilla while GTK3 hasn't gotten stable yet, which will make life for anyone that tries to build a GTK2 variant very hard. Therefore, I wouldn't really say it's an easy choice.
That points towards GTK2 support possibly not being functional, which could be a good reason why they don't provide a build for it, even if they wanted to.
It sounds like the real problem here is that Mozilla is changing stuff that some people don't want changed. I don't think the solution is to ask Mozilla to produce a GTK2 build, but to ask them to fix anything they've broken. If they've decided to move towards GTK3, then that's their choice, and presumably they have reasons for that choice. I don't think it's out of line for them to expect to support a single working build for an architecture/OS combo. That said, they can and should be notified and pressured to fix any regressions. Additionally, if the change is something people don't want, Mozilla should be notified of that (although I suspect there are technical reasons for the change that most people are ignoring).
I agree with what you say and want to add that there two issues here. First is the GTK3 port of Firefox not working as a native Wayland GTK3 window. Second is the themeing issues with GTK3 that people ran into, which is something you can live with. Finally, it's the serious regressions of GTK3 itself which go unnoticed or ignored as evident in the gnome.org bug-tracker and the tickets I've linked to in a sibling comment.
The most important argument for Mozilla providing GTK2 builds is that otherwise the likelihood of the code bitrotting is very high as it happened with the Qt port. The interesting aspect of the Qt port was that at that point in time GTK2 was the best choice, but now for substantiated reasons major applications chose to rather port to Qt than GTK3. Therefore, if the Qt port were to be revived it's much more likely to be of interest and maintained than back when the GTK2 port was good enough that nobody cared about Qt.
I know X11 and Wayland are not Mozilla's main platforms of interest and I'm grateful that they do support with the feature set they do. I'm surprised at the seemingly isolated echo chamber perspective of the GTK3 devs. It's an interesting behavior to observe since without non-GNOME users it could just as well be rolled into GNOME itself. Interesting times, having lived through the times when jwz in 1998 was debating whether GTK1 was any good for Linux.
Is that officially supported yet? I see that back in June/July experimental support was released. Possibly is the current work in an effort to get that working, but it's not ready yet? I just tracked down what looks like the feature tracking bug[1], and it doesn't appear to be ready, but I could be reading it wrong.
> Second is the themeing issues with GTK3 that people ran into, which is something you can live with.
Sure, but from my own problems with themes in Chrome, it's not something you want to live with, especially if you used themes to signify instance information and they stopped working, so I feel people's pain there. :/ Preferably Mozilla would have kept this gated in a branch or experimental build until these issues were worked out. That said, earlier today I did see something about plugins built using GTK2 being loaded into Firefox with GTK3 and the symbols loading wrong, so perhaps it's a much harder problem than it seems, and if it requires theme's to rebuild, then perhaps the quickest and easiest way to make that happen is to force a little breakage. Then again, the distro build probably makes sure this isn't a problem.
> I'm surprised at the seemingly isolated echo chamber perspective of the GTK3 devs.
I imagine that's somewhat to do with where their focus lies. I'm under the impression that a lot of the funding comes from Red Hat, so there are likely complex motives at multiple levels from the enterprise to the funded developers (who might want to justify their paycheck).
In the end, it's one of those things that's hard to accurately critique as an outsider, because there's a lot of specific information that goes into a decision like that. Is a GTK2 to GTK3 migration easier than a GTK2 to QT (or some other toolkit) migration? Probably, but by how much? If this was happening a few years ago, we might be complaining that Firefox uses a toolkit (that is, underneath their own toolkit) instead of X directly. Now we have X and Wayland, so that wouldn't have presented a similar situation anyway. In the end, unless you have some upstream vendor willing to put lots of time and money into making sure you have a performant, backwards compatible API to call (e.g. Microsoft), you'll probably want to make changes at some point in any long-lived project.
For anyone else interested, it appears that the patch is still being reviewed - https://bugzilla.mozilla.org/show_bug.cgi?id=1151899 (though I don't know if rust-url would have actually prevented the issue).
I don't have the equivalent Evernote plug-in anymore (I'm trying to get away from Evernote), so I have nothing to compare it to.
https://bugzilla.mozilla.org/enter_bug.cgi?product=Toolkit&c...
I found another article where it leaves the author photo but removes the main article photo (https://www.washingtonpost.com/opinions/david-camerons-wizar...) so I believe it is a bug.
BTW, I think this bug covers the issue (it's where I got the WP link from):
https://github.com/mozilla/readability/issues/219
Edit: Actually, this is a better bug report:
Is there any evidence you've found of any publishers intentionally trying to load assets in a way that would break with this because it is stripping some ad impressions?
PSA: Please update immediately. One of these is critical.
I'm using Iron Browser now, which has its own issues, but which at least handles a hefty amount of tabs and some essential extensions without destroying system performance.
uBlock was to my knowledge never developed to securely stop scripts and deter drive-by attacks etc. It should be used for adblocking, not for security.
http://www.ghacks.net/2015/11/24/noscript-script-surrogates-...
>When you visit a site in Firefox that loads the Google Analytics script on page load, NoScript intercepts that request and replaces it automatically with the replacement instructions (which basically tell the site that the Analytics script was loaded fine but does nothing in regards to user recording).
1) Is the site requesting a "no-referrer" policy? Then send no referer.
2) Is network.http.sendRefererHeader set to a value that would prevent sending of referrer in this situation (e.g. 0 in all situations)? Then send no referrer.
3) All the other logic (but generally aiming to follow the most restrictive directive we have).
The "network.http.sendSecureXSiteReferrer" still exists in 50, but is gone in 52; see https://bugzilla.mozilla.org/show_bug.cgi?id=1308725
I guess the reason why it's confusing to people is that Firefox (just like Sublime) doesn't have that little popup displaying a list of tabs while switching, it would make all the difference in the user experience, and make things clear.
This extension is even better IMO. And so far I'm enjoying having better tab handling and a much faster browser.
At least visibly better than the 49.
Now I absolutely HATE when a update is released, because either functionality is removed, appearance is changed or even more bloat has been added.
Firefox itself has become the problem it tried to solve.
Added a built-in Emoji set for operating systems without native Emoji fonts (Windows 8.0 and lower and Linux)
EDIT: just got the update and it a) fixed some emojis I somehow didn't have, namely "thinking face", which is of course critically important and b) made the rest look a lot livelier.