> Improved performance for Mac and Linux users, by enabling link time optimization (Clang LTO). (Clang LTO was enabled for Windows users in Firefox 63.)
If this release makes it actually usable on MacOS I would be so happy. Everyone says to use FireFox here, but they don't realize that it runs horribly on machines that a lot of people use to develop on.
Reading the release notes:
Improved performance for Mac and Linux users, by enabling link time optimization (Clang LTO). (Clang LTO was enabled for Windows users in Firefox 63.)
Doesn't seem like this fixes the high CPU issue on MacOS.
Maybe in another few dozen releases they'll fix it. Doesn't Mozilla realize how many people develop on MacOS? Everyone I know develops on a Mac.
To be clear, this doesn't affect all macOS users. My battery reliably lasts a whole day with Firefox running throughout. That said, the subset of users who are affected, like you, suffer a lot - low prevalence, high impact.
In my case, CPU usage goes to the roof if I use a scaled resolution instead of the default one. If that is the case with all macOS users with non-default resolution, I wouldn't call it low prevalence.
Not an issue for me. I have a imac 5K and a retina mac book pro. Both with image scaling on by default. I think most recent macs have retina now.
I use Firefox exclusively and have done so for the last 2 years or so. This sounds like it could be a driver issue for specific macs. Both my macs have AMD Radeon chipsets & quad core i7s.
Anyway, I'm sure this issue is real. Bugzilla ticket numbers probably exist for it and might be more helpful than vague complaints about things being slow.
Of course some web sites are a bit unreasonably javascript heavy these days. The downside of a large screen is that pushing a lot of pixels around is not free. Usually closing any offending tabs immediately restores any cpu usage I see. I'd suggest using the new task manager thingy (page menu->more->task manager)
Anecdotal, but I've found it happens when image scaling by a factor other than 2. Affects my setup of a 4K display at 2650x1440 effective resolution, or 1.5x scaling.
Exactly this. I run at 1920x1080 effective resolution on my 15" rMBP, and 1680x945 on my 13". I see the issue on both.
When I switch to the "default" scaling (1440x900 and 1280x800, respectively), it stops. Only the 15" has a discrete GPU, eliminating that as potentially causal.
When I interned at Mozilla, most of the FF devs developed on a Mac. They are not ignoring the platform. I suspect the issue is as other said, low incidence, high impact.
I use only Macs by default. It runs great and has for years. There's probably a real issue somewhere but it's far from as universal as your post implies.
Likewise. Not aware of any weird issues with performance in relation to Firefox. I use it exclusively. I'm on the beta channel. I can't remember the last time I had a browser crash. I generally restart it to apply new updates every few days or so.
If you have performance issues; you might want to check whether you need to blame the browser or some of your extensions.
Seconding your last point — almost every time I've had someone complain about generic Firefox or Chrome performance the problem went away as soon as they restarted it without extensions. There are certainly exceptions but misattribution is common enough that I'm not surprised to see browser vendors adding the UI to make it easier to discover.
This is a known issue, and has been around since at least v57. There are multiple Bugzilla issues on it. The cause is known. It isn't extensions. The fix is just invasive, and apparently ongoing.
That’s true but not what this thread was about. The person I responded to above was making a very broad claim, which is wrong, and jillesvangurp agreed with the observation and added a general point which is correct. There is a specific issue affecting a subset of people with less common configurations but that doesn’t make the sweeping claim true or the recognition that browser performance issues are notoriously poorly attributed untrue.
Do you require a scientific study for any fact? If you bothered to do any googling, or whatever Mozilla equivalent of google is - this is in the top 3 results. https://9to5mac.com/2016/12/02/15-inch-macbook-pro-screen-re... Scaled resolution is defaulted on a huge amount of Macs.
I asked for data because humans are very prone to confusing things which affect them personally with the general case. Since Mozilla uses telemetry heavily I tend to trust their prioritization more than random self-selected commenters.
The thread-parent absolutely cast a wider net than warranted, but everyone in this discussion who has experienced this problem knows exactly which one we're talking about, and the rest are all, "I've never seen a problem!" or "It's probably just extensions." Meanwhile, there's reliably a sub-thread somewhere in the discussion on nearly every article about Firefox, about this problem.
I find it profoundly ironic that you comment down-thread that "humans are very prone to confusing things which affect them personally with the general case" about a thing which you haven't personally experienced. You talk as if those of us for whom this is a 100% reproducible problem are an edge case, based AFAICT solely on your own not suffering it, coupled with your (not incorrect) beliefs about people poorly attributing performance problems in general.
I was aware of the issue already but that’s also why I knew that the biggest impact comes from a non-default setting. I never said that it wasn’t a real problem, or that it doesn’t warrant attention — only that it wasn’t as broad as claimed and that is a very common problem with browser issues because everyone uses them but people who don’t have problems generally don’t go around posting that everything is fine whereas the percentage of users who are affected will complain regularly.
I have used Firefox since the early 2000s, and it has been frustrating to see performance get worse even as my hardware gets better. I realize that this is mainly the fault of bloated websites, but I can also see that Chrome and Safari are faster than Firefox.
I recently switched to Brave Developer Edition [1], which now supports Chrome extensions (which I need for work/pleasure). It runs circles around Firefox and Chrome, and maintains my privacy better.
Previously it was a tradeoff of getting speed (Chrome) or maintaining privacy (Firefox). For me, Brave does better on both counts, and now that it supports extensions I'm completely sold.
If Brave is running circles around Chrome for you in general, that's likely a result of cognitive bias, since last I checked it's the same rendering engine.
For pageloads Brave might do better if it blocks various stuff by default, of course.
I am quite aware of what Brave's value proposition is. Generally when people are only talking about pageload performance they say so, because there are many other performance metrics relevant to web browsers, some of which are arguably more important for most users...
Anecdotally, it seems to be flying through pages it used to struggle on when I last tried it (~version 60). Tab switching seems faster too, but I haven't had enough time to put it through its paces yet. Fairly promising so far, though!
I've been suffering from these performance issues since I started trying Firefox again around version 57. I can say that this version finally feels like they've fixed the performance issues, at least for me.
That said, I've thought this before and turned out to be wrong. But it looks like it might be real this time.
> Easier performance management: The new Task Manager page found at about:performance lets you see how much energy each open tab consumes and provides access to close tabs to conserve power
> Improved performance for Mac and Linux users, by enabling link time optimization (Clang LTO). (Clang LTO was enabled for Windows users in Firefox 63.)
> Easier performance management: The new Task Manager page found at about:performance lets you see how much energy each open tab consumes and provides access to close tabs to conserve power
This is pretty neat, now I'm wondering why the webex extension is having "Medium" impact when it should be doing nothing.
At least it's not Google Hangouts. That crap platform will kill any laptop battery in ~30-45 min flat and make it seem like you're rendering some 8K video.
I'm sure those who build it themselves could have enabled this in earlier versions already, and I assume this means the pre-built binaries now enable this.
The binary should ship that way unless your distro decided otherwise. You can easily check by going to about:buildconfig and seeing which compiler was used.
EDIT: Dang, guess the spittle brigade is really out in force today. Anyone downvoting want to maybe respond in substance as to why they think Firefox should continue ignoring security issues that have been open since the Bush administration?
The same person who managed to make the text and background color not clash will also be able handle two scrollbar colors responsibly. Take e.g. a textarea that gains focus and has the both scrollbar and border change color, what's so terrible about that?
No sarcasm, and that question wasn't rhetorical either: How is a scrollbar that different from other input elements within webpages that can already be styled?
And what do you mean by using non-default colors? User stylesheets would also include scrollbar colors anyway; do you mean just setting a background but no text color (assuming a default of black, which might not be black for the user)? Don't see how this could apply to this CSS property, since it takes two colors, you either set both or none.
It seems logical to me that if you can read the text on the web page, that is, if the web dev hasn't made the common mistake that renders the text unreadable, they will set the scrollbar colors to something of similar "quality". If you can't read the text because they use CSS badly, then the scrollbar color is the least of your worries. QED?
Generally speaking, there are a lot of "common webdev mistakes", like using the giant images and scaling them down, having text and background color very close together... but we don't take that away just because some abuse it, so resisting more flexibility on those grounds doesn't strike me as so "obvious" as people seem to agree it is. If you can allow websites to hide the mouse cursor, I don't think the web will break because of this CSS property. If you don't want to see it on any page, override it in your user stylesheet, done.
What do you mean, as well? That's the only bit you didn't ignore.. and it's useful for when you draw your own cursor in WebGL. I can't think of a single time I ever saw it abused, I guess I don't frequent the kind of website that would.
By "as well", I mean "as well as objecting to web devs being able to alter the appearance of browser controls".
Yes, I do see the usefulness of being able to do all of those things, but in practice, I don't appreciate it when it's done. I'm not saying that it's abusive (and I'm not talking about egregious misuse of these abilities), I'm just saying that I personally dislike it when sites do this sort of thing.
I fear that I've come off as too militant on these issues -- as a web dev, you should do what you deem best. As a user, if your choices are too annoying to me, I'll just avoid your site.
I think this whole thing just plays into a personal issue I have over the web these days... from a usability and aesthetic standpoint, the web has been noticeably declining for me over the past few years.
> I do see the usefulness of being able to do all of those things, but in practice, I don't appreciate it when it's done.
That I can certainly agree with. I also think users should be able to override and customize things... ideally, everybody gets more options? And user agents should absolutely be user agents, instead of brochure displays.
While design may be somewhat subjective, I also think websites are getting worse. If that's a "personal issue", we both have it :D Just the last one I just looked at, that made me think "why? who is this for?"
I just think marketing (and mobile?) play a much larger role in the downfall of the web and the rise of generic copy drowning in padding, than all the stuff we can do with CSS.
That's the point.. since you probably woulnd't argue for taking away background and text color, you already "trust" web devs with those. If a website is unreadable, the scrollbar doesn't matter. If it's readable, the scrollbar will look great, too. Also see other comment.
> That's the point.. since you probably woulnd't argue for taking away background and text color, you already "trust" web devs with those.
I would, reader modes are a godsend that revert the web back to how it should have always been, with the client controlling the text and background color in a way consistent with the rest of the system.
Content display should be up to the user, not the designer.
I never used them, but Opera had a few preset user stylesheets right there in the "view" menu at the top of the window, that was neat. One was "C64" IIRC. Silly, but neat ^^
If styleesheets could have placeholders for some system colors (maybe even fonts?), that could be something.. turn nightmode on/off, or just generally change colors, and all programs and all websites fade! I would actually love "having to" make 3 stylesheets, one super fancy one, a print stylesheet, and a "system colors" one. Or don't even stop with colors, do it like Magic User Interface on the Amiga, let the user configure how they want all sorts of input and information fields to be formatted and behave... some people want material design (they're wrong of course, but if they must be wrong, I want them to at least be wrong and happy, rather than wrong and unhappy), others want gradients and bevels and shadows everywhere, let everybody set it how they want. Some people want lots of padding, others want tight padding and negative linespacing and tiny fonts, etc.
Awww, now I'm super excited about something that doesn't exist... I can taste it, it would be so awesome! This is the wrong timeline :/
Those controls are not part of the content, they are part of the application or operating environment itself, and I have configured them the way that I want them.
As such, they should be off limits to web designer's whims.
As an aside, my experience with web sites over the years (particularly recently) doesn't exactly give me a great deal of confidence that they would make appropriate choices for the appearance of these controls.
> Those controls are not part of the content, they are part of the application or operating environment itself, and I have configured them the way that I want them.
Depends on the browser, but e.g. text area colors can be styled anyway (and therefore made unusable, how irresponsible that CSS allows for this), and whether scrollbars show up in the first place is CSS, too. You can override that with user stylesheets if you want, but no need to hardcode that for everybody.
> doesn't exactly give me a great deal of confidence that they would make appropriate choices for the appearance of these controls.
You're now the third person to say this, and the second to do so while ignoring what I responded to that point, so again:
If you can't read the text, why do you care about the scrollbar? If you can read the text, why do you worry about the scrollbar? In what conceivable practical scenario do you gain anything? The very same people who picked all the other colors might also color the scrollbar, but how is going to make a default scrollbar make an otherwise unusable site usable?
We can already hide scrollbars, but coloring them differently, that's a problem? I don't buy it, as they say. How is an ugly scrollbar, or one that uses the same color twice and is unusable that way, worse than none?
Answering my own question... it is, indeed, markedly better than the last new release I tried. It was really janky looking for a while. It still doesn't look as clean as Chrome's tab bar, but it's reasonable now. So props to the Mozilla team on that.
I think I liked the more triangle shaped tabs as well, but w/r/t Firefox, there was a recent release (couple of months ago?) where the tab-bar was all kinds of jacked up. Maybe it was just a short-lived bug or something... what it was, it looks a lot better now.
Is this the version that kills Live Bookmarks? Some of us FF old-timers are hopelessly reliant on these things, and it's, as far as I have found, the fastest way to quickly scan lists of headlines from all your favorite sites at once. Seriously, one click and you can quickly mouse over the sites on your bookmarks toolbar to consume hundreds of headlines.
Mozilla did the same with tab groups, then the addon was abandoned. The replacement that is compatible with the new form of extension isn't able to unload the tabs, just hide them, which undoes most of the performance benefits.
[abraham simpson voice] It'll happen to you too! [/abraham simpson voice] /jk
Which can be worth it depending on what you trade it for. I really liked the tab group feature but the new extension API is vastly more secure and can (probably) be extended to allow for most addons.
At Mozzila they need to prioritize many different things and I can understand how a constant push to make the browser leaner is foundamental. (especially in cases like RSS feeds)
It's true that it wasn't widely used, but it seems as if Mozilla did their best to make it that way. It wasn't exposed to the user by default, but instead was hidden as something you could get to by the toolbar customization screen, so you had to modify the toolbar to even get access to the feature.
The addon was abandoned by its author because Mozilla was making major changes to the addon API at the time. Extensions used to have carte blanche to change the browser, which was a security risk, not to mention it made threading/parallelizing the browser hard. The new extension API removed a lot of that freedom. After the API change, it wasn't possible (and might still not be) to develop a useful tab groups addon with the new API, so the author ceased development.
I can't imagine Mozilla crippling the addon API to the point where it can't grab data off an RSS feed and display it.
I was probably wrong about next too, then. Still, they both hail from the Steve Jobs school of blurry fonts, which is all any sane person tries to avoid in a web browser ; )
That’s like saying everyone is at risk of bear attacks because a few people in rural areas do get attacked. Yes, extensions exist but when was the last time someone clicked on a link in an email and installed an emacs extension? That happens daily to thousands of web users because the population is so many orders of magnitude greater.
> The replacement that is compatible with the new form of extension isn't able to unload the tabs, just hide them, which undoes most of the performance benefits.
Firefox 64 introduces an entirely new API, browser.menus.overrideContext, which allows complete customization of the context menu shown within add-on content like sidebars, popups, etc.
This is illustrated right in the post by my favorite pain point, the Tree Stye Tab custom tab menu mixing with the regular tab menu.
arrrr... what they don't realize when they review their telemetry data is that most people that use this feature have turned off sharing telemetry data. Combine that with the fact that they haven't advertised the feature in the past decade and it leads to devs thinking nobody uses it.
Then perhaps you can see why telemetry is useful to responsible companies like Firefox, and maybe people who disable it have no right to complain about decisions based off telemetry data?
No, this is supporting direct feedback. How can mozzila know which features are useful in your opinion? how should they know that you wanted [feature X]?
Maybe they are also in the wrong if the telemetry is excessive, but the alternative is to never deprecate any feature ever.
They could ask slightly more focused questions than "what would you like?".
Better than keep removing features and reasons to use Firefox from some of their loyalest users, even if they are a minority. User retention seems Mozilla's largest issue at the moment now they're down under 10%.
Ask who? Power users? Then the only signal they would get is "every feature is used by everyone". That's worthless 'data'. Telemetry is the only way mozilla could possibly collect real data.
when google recently made chrome automatically sign-in once you login to a google site, i read one of their technical managers basically say, "all our data shows users care more about the convenience than the privacy" -- i thought exactly that.
The usage stats from telemetry showed a 0.01% usage rate. Even if 99% of people that used the Live Bookmarks feature disabled telemetry that implies that 99% of Firefox users did not use the feature.
Well, Firefox killed the RSS button on the URL bar a while ago now (bring it back with https://addons.mozilla.org/en-US/firefox/addon/awesome-rss/), so AFAIK there has been absolutely nothing to indicate the feature even existed for years now.
Also, 0.01% of a big number is still a big number, and given the state of the feature, that number is likely to include a lot of long-time users.
According to Mozilla's statistics, 0.01% amounts to only 80'000 browser installs that use live bookmarks. That's not a big number and it's easy to find features that more people care about (ie multi-tab selection).
When resources are constrained you have to make decisions about what features you'll continue to develop and which to cut out. Live bookmarks was cut out. Mozilla devs have also mentioned that this feature is ancient code and would have required a lot of coding effort to bring up to date.
I'm sure if you were to invest the time to reimplement live bookmarks with modern code and with the internal restructuring in the browser in mind and you'd volunteer to maintain it and fix all filed bugs, they'd accept it.
It's really weird to apparently be personally part of a 0.01% group. I feel that usage rate must be suspect- in some Firefox version they gave out live bookmarks by default, and surely more than 1 in 10,000 people still have those. Do we know what the telemetry actually measured?
Given how long ago it is since live bookmarks were a feature they made obvious, or called attention to in any way, in the default install, that's not so surprising.
They removed the visibility years ago, then progressive updates made them ever less visible, including hiding then removing RSS notification. Once the first step was taken, the route to removal was set, including the telemetry figures.
If they were as visible as pocket, perhaps as visible as pocket stories on new tabs, usage would be hugely higher.
The best thing about RSS reader in Firefox for me was the fact it blended perfectly with bookmarks feature - it was easy to reach especially when you had bookmarks bar enabled. The way it displayed content also suited me - I didn't have to break my browsing flow to open another tab like in Presto-based Opera or special feed with summaries like in Safari; links in form of bookmarks changing titles were absolutely best.
A web browser today is essentially an Internet-facing client-side operating system. You are suggesting to use something that runs outside this OS. (Just pointing out.)
I added Livemarks. It helps, but it's still missing a critical feature of the old extension- the icon showing which RSS links you've already visited. That'll be added at some point at least:
Still, this update felt particularly user hostile. My user experience was:
- I'm in the middle of browsing and open a tab to do a search, but the new tab shows the "Firefox needs to restart because updates are more important than you!“ page.
- I'm forced to restart. Manually, since the automatic restart is probably broken on my system. Tab state in some SPA tabs are lost.
- Now I have to migrate my live bookmarks. They converted themselves to regular bookmarks- I have to right click and delete those one by one. Then I install Livemarks, import the exported bookmarks data, and then drag those one by one to my bookmarks toolbar.
I'm half considering Chrome. If Firefox is going to be like this, why bother? Might as well start the Chrome dominance and stagnation part of the browser cycle.
I am a _huge_ RSS user (TinyTiny-RSS) but I don't think enough people used these features to continue supporting them. Plus, I really do not want my web browser to be an RSS reader. Have you considered moving to a dedicated RSS reader ?
on Windows you will always have a white scrollbar even with dark theme enabled in Windows and firefox, and if you are then on a dark website the scrollbar is basically a beacon of light
Given that WebKit recently added "Dark Mode" support, it would likely be sufficient for Firefox to do the same and simply recolour the scrollbar itself, rather than trusting CSS artists to do it sanely and properly.
You're assuming the only scrollbar is on the far right-hand side of the screen. There are plenty of inline scroll bars and scrollbars in parts of the UI that are not adjacent to "native" chrome. Always using the OS default does not make for a good experience.
I don’t see in anything I wrote any implication that I assumed anything about what scroll bars needed or would be themed.
A browser-wide scrollbar styling system, able to be opted into by use of particular CSS, doesn’t imply anything about whether we are talking about just one scroll bar or all of them.
I also disagree about native controls not always being the best solution when it comes to scrolling. We all know how annoying it is when a page jacks scrolling; it’s a usability nightmare that makes pages’ scroll behaviour harder to predict. We don’t need to add to the usability issues by letting one of the most fundamental pieces of chrome in a web browser get jacked even further than the already impermissible state.
Not really, it's the same concern; the potential for gratuitous, superfluous, or regressive modification of a stable and predictable user interface element that is representative of the most fundamental of actions when it comes to long-form document-based design: scrolling.
I have a trackpoint with no 3rd button. Many trackballs don't have scroll wheels. Many folks use arrow keys and space, shiftspace, pgup/down to navigate too and those require nice visible scroll bars that move the whole document to navigate effectively.
Long story short, stop fscking with accessibility. If your js code or libraries handles ANY input events, you'd better watch yourself because you're venturing into specialized-interface-by-and-for-assholes-land.
Things like large documents don't make that any easier though. Scrolling through a large document can take a while, but a scrollbar allows you to get to somewhere else often quite a lot faster.
Imagine you cmd + F a phrase and there are 200 responses separated into like 4 chunks of a document. It can be useful to scroll to the start of each chunk to get the context of them.
Most new mice, yes. I use an original Logitech MouseMan 3-button mouse with no scroll-wheel. I realize I'm an outlier, but no mouse has ever come close in terms of comfort for me - so I continue to use it, and life has been just fine until the advent of the Overlay Scroll Bar.
I realize the benefits of the Overlay Scroll Bar to the majority of users who have scroll-wheels. But it sure would be nice if there was an easy way to revert back to the Normal Scroll Bar ("Classic" scroll bar?). You know, the wide bar that scrolls down exactly one page-length if you click outside of the bar? I've spent plenty of time Googling and in "about:config" and exporting environment variables like GTK_OVERLAY_SCROLLING=0 to no avail.
This assumption should be listed in the Firefox "System Requirements", then. I'm pretty sure nowhere else on my system (Mac) requires the mouse to have a wheel or tracking surface, or even a second button. Just x/y positioning, and clicking.
Time for FF's balance of configurability and reasonable defaults to shine: the about:config properties to edit are `layout.css.scrollbar-color.enabled` and `layout.css.scrollbar-width.enabled`.
I imagine you could set up a scrollable div on a page, with elements within and query the position of those elements or their width. Having a custom scroll bar would flow the contained elements in different ways depending on how wide it is.
One thing I like about the Firefox (Gtk?) scrollbar is that it finally removed (a few version ago already) the "Click on it somewhere, but it doesn't move there but just acts like PgDown/Up", i.e. the non-warping to the exact click position but just inching towards it. This is completely unnecessary in the time of wheels and touchpads and I already miss it everywhere else.
But, that is what PgUp/PgDown are for on the keyboard, no? When you are navigating in these discrete steps why use the mouse, which is excellent for continuous input. If I click on something, I want to go THERE, not in the direction of it. "But we have always done it in this (imo illogical) way" is just being stubborn.
> that is what PgUp/PgDown are for on the keyboard, no?
Definitely no: If I have a hand on the mouse I surely don't want to lift it and hunt for the PgUp or PgDown just to move one page up or down. And no, I don't want to go "there" if it's actually "somewhere" in the middle of whatever, if I just want to see the previous or the next page. Going "there" is much less frequent operation than moving to the next or the previous page.
So, that means a PgDown button (I guess it is mostly that direction) on the mouse is missing. The thumb button which most mice have and are mapped to forward/backwards could be remapped to that. Or a mouse gesture? FoxyGestures, a Firefox addon, has a "Scroll Down" action.
"Most"? Where did you get that idea? "Most gaming mice" or what? Most of the users aren't gamers.
> that means a PgDown button (I guess it is mostly that direction) on the mouse is missing.
Of course is missing: "normal" (as in the most common) mice have only 2 buttons and the scroll wheel.
The scroll wheel never moves one page up (or down), but just some small number of lines, so the most common operation is then impossible for the most of the users just because a developer (who probably even "lives" in his terminal for most of the time, never lifting the both hands from the middle of the keyboard) thinks that everybody has exactly the gear that he has.
If you have a keyboard which has those and it doesn’t require moving your hand off of the mouse to hit them, it might be easier. Many smaller keyboards (e.g. most laptops or Apple’s non-pro keyboards) either omit them entirely or require a modifier key.
On Windows another lovely scrollbar "feature" is that if you move the mouse too far left while dragging the scrollbar the scrollbar will jump back to where it started.
A handful of people love it, most think it's a bug. It's particularly bad if you're using a trackpad.
I would theorize that it's not a well known complaint because most people move on quickly and just assume their computer is buggy.
I am working on a HTML5 game which has a list of rooms, list which has a scrollbar. It looks as ugly as it can be with the default scrollbar when everything else is neatly designed and has a specific theme, it ruins the immersion and reminds you hey, this is just a browser game, not a real game. I am not saying that all the sites should have custom scrollbars, but there are definitely use cases for it.
Customising UI elements is a usability antipattern.
Per [1], predictability and familiarity are key in creating usable interfaces. Making things look nice "because you can" doesn't necessarily mean you should.
> When designing your interface, try to be consistent and predictable in your choice of interface elements. Whether they are aware of it or not, users have become familiar with elements acting in a certain way, so choosing to adopt those elements when appropriate will help with task completion, efficiency, and satisfaction.
Just curious: does this principal apply only to scrollbars or should sites not be able to change the appearance of other controls -- like buttons, for example?
I'll reply here to both you and baroffoos, it's basically the same question.
> Does this principal apply to X for y?
In a vacuum, yes it's a principal.
In reality, while it's an antipattern it doesn't mean you should be afraid let alone disallowed the ability to exercise good judgement and make a call.
Full window, emersive games are the perfect example of UI elements like buttons that should probably be reskinned - wisely. I say wisely because you can still reskin buttons in a way that affords familiarity you can also reskin them in a way that makes them abhorrent.
A converse example is windows based skinnable hardware interface software like MSI afterburner and the like. That sort of thing is absolute unthought, untested garbage.
For website buttons I think the ship has sailed and the default elements actually look alien.
In fact a lot of CSS frameworks improve net usability from defaults anyway.
Now, is it an antipattern to use them? In essence yes, but considering everything no. Caution, many css frameworks have UX issues and you need to make a judgement in your evaluation about which features to use. I like to see how their autocomplete / dropdown features work it's usually a good litmus test because those things are basically impossible to do right.
And this why we have UX people.
It is the marriage and trade off of usability/hci and designers to create a usability experience that delights.
Though things still tend to lean toward design first approaches. Which aren't incorrect approaches but do tend to lack emphasis on circling back to fix usability later.
I think website internals are widely debatable but do have norms you must consider.
I draw the line at breaking out of the window sandbox and altering browser UI. It assumes all browsers work the same and creates a dependency on the browser for a shared experience.
An inconsequential example: setting browser ui color on mobile version of Chrome. Now your whole website design feels very native and is reasoned about with that native feel. That can them lead to inconsistent design assumptions being made on the desktop. Maybe your color selection clashes badly with the desktop grey.
Like I said, inconsequential, but might illustrate why messing with it might be a bad idea.
The other big reason I throw down at the browser window line is accessibility. Messing with things like button sizing / scrollbar sizing and things wrecks absolute havoc on these users. They also make English centric assumptions about designs that are almost always wrong eventually.
Have you ever seen a game built entirely out of default OS windows and buttons? If you are building an accounting program, sure use all the defaults but if you are building a piece of art I think you can afford to change a scrollbar.
Oh, I know I'm hell-banned. That's okay, Mr. Paul Graham will be getting his comeuppance in PUBLIC very soon. :) I know some secrets and I can't wait for him to be anywhere near my area so I can publicly expose him.
I don't think that discredits my point or it's information. If anything it points out how much of a problem this stuff is and how uninformed (or at least disconnected) developers and designers are.
Every other browser allows styling scrollbars using CSS. Firefox was the only one that didn't and there's a 15 year old open bug on bugzilla about it.
The work around was to use JavaScript, just to make it work on Firefox.
It can now be implemented in CSS, which makes it really easy for you to disable or change your preference as well putting the responsibility of style on CSS and not some annoying JavaScript.
In case anyone else is confused as I was, the "64" in "Firefox 64" appears to be the version number and not referring to a 64-bit edition or something other special edition.
Kind of a niche thing to comment on, but this release lands a commit I made that enables XDG desktop portals support in Firefox. If you're on KDE Plasma, you can run Firefox with the environment variable `GTK_USE_PORTAL=1` set and it will use KDE file selection dialogs.
Very cool, I don't suppose this will allow one to change the dialog in hybrid/non-DM environments also? I use Openbox with a mix of KDE and GTK apps and this is one of the more common annoyances. I looked into this a while back and couldn't find any info at all.
This depends on what `xdg-desktop-portal` DBus service is running on your setup. In most non-DE environments, there is no `xdg-desktop-portal`, and as a result, GTK will automatically fall back to GTK file selectors.
If you'd like to use KDE file selectors in a non-DE setup, you'll need to get `xdg-desktop-portal-kde` working.
Indeed, and thanks for pointing that out! I am not a fan of the simplified Gtk file dialog, even though I learned the trick of pressing Ctrl-L to edit the location. Let's see if that works with other Gtk apps. Edit: `GTK_USE_PORTAL=1 inkscape/gimp` does not work, seems it requires sandboxing? The xdg-desktop-portal-kde package says "This allows sandboxed applications to request services from outside the sandbox using KDE GUIs".
The environment variable only works with apps using GtkFileChooserNative, a GTK3-only API that landed in GTK 3.20. (In Firefox, my patch will fall back if you have an older version of GTK3.) GtkFileChooserNative was designed for use by sandboxed Flatpaks, but the environment variable can force it on outside of a sandbox.
It might be niche in the grand scheme of things, but for me this is an incredible improvement on my usage of Firefox. This was honestly one of the few things that Chrome did better. Firefox was the only program that I use every day that forced me to use the GTK file selection dialog. Thank you very much!
This isn't a niche thing at all! Assuming you can get xdg-desktop-portal-kde working independently (and I expect it's possible), it's useful everywhere, not just on Plasma. The default "Open File" dialog in GTK 3 is atrocious.
Right now, this is automatically enabled based on whether the application runs in a Flatpak sandbox. I spoke with GTK developers on IRC, and while they want to enable it by default, there are some unresolved issues, summarized in this Reddit comment: https://www.reddit.com/r/firefox/comments/9my9fe/qt_file_pic....
I am sorry to be the one to ask, as it seems all the other commenters know it already. I even searched internet for "What are XDG desktip portals", but this came up with results for project that seem to use these portals, but no fast explanation of what they are? Can please somebody summarize what this is about?
Disclaimer: I am a Linux user since >20 years, using XMonad window manager on Ubuntu 16.04 at the moment.
Not yet. There were some A/B experiments in Firefox 64 Beta for Windows users with Nvidia GPUs, but there are still some bugs to fixed. You can manually enabled WebRender in Firefox Nightly builds (but not Beta or Release channel) by setting the "gfx.webrender.all" about:config pref to true.
AFAIK it's enabled by default in Nightly for some desktop Windows users. There's an about:config pref that others can use to enable it. Follow the WebRender blog for more information: https://mozillagfx.wordpress.com/
You have no idea how excited I am for this. I use sway as my daily driver since it supports HiDPI so much better than i3, but the one caveat to that has been firefox and xwayland. Once this ships, sway will have nearly flawless HiDPI support.
Yea, I too love Sway and use it as my daily driver. I recommend you use the non-packaged version 65 or newer of Firefox, just need the GDK_BACKEND=wayland environment variable set. Only issue is due to the current state of Sway there are some drag-and-drop issues, but that's not a Firefox thing.
xclip works fine for me on wayland (Arch), the rest... yeah, colorpicker? doesn't work. Screenshot? Gnome tool works but grabbing an area has a weird tainted color.
In my experience X11 has zero shortcomings compared to Wayland. The code might be ancient and arcane at some points but the performance and features (hello "ssh -X") are actually far superior.
I have never been able to get a tearing-free experience with X11, and I've tried everything to fix it. Meanwhile Wayland is butter smooth out of the box on the same hardware. Security is another obvious advantage of Wayland.
Just another data point: I've never experienced screen tearing in the decades that I've used X.
Also, when I run X just for myself on my own laptop, what security issues do I have to worry about with X that I don't have to worry about with Wayland?
That's interesting, because I've had tearing issues with all major GPU brands (Intel, AMD and Nvidia), in particular when multiple monitors are involved. What's your setup like?
With regards to security, the main issue is that X11 provides no isolation between applications, allowing them to listen to keystrokes and the clipboard at all times. With Wayland, only focused applications have this access.
Currently I'm using an old, slow laptop, with a graphics card integrated in to the motherboard. Nothing special. But I don't do any demanding graphics processing on it. I just watch movies and use web browsers and a terminal. I don't play graphically intense games on it.
"With regards to security, the main issue is that X11 provides no isolation between applications, allowing them to listen to keystrokes and the"
I don't see why this should concern me or 90% of X users, because if any malware manages to run on our systems it'll already have full control over them without needing to resort to any kind of keystroke sniffing in X.
I'm struggling to think of a scenario where malware's running on the same machine with access to a single X session, which doesn't already have full control over the account whose keystrokes they'd be presumably sniffing. They could just substitute their own malware versions of web browsers, shells, editors, or whatever other software the user uses and sniff keystrokes in there, without needing to touch X.
Not that it hurts to have more isolation than you get in X, but I'd need a lot more convincing for me to give up the convenience I already enjoy with X.
Can someone paint me a realistic, relatively common threat scenario where not having Wayland's isolation would actually present a serious security risk?
Right, if you already have malware running on your system, all bets are off. However, I'm sure you're aware that large applications like Chromium have tons of vulnerabilities, which is why they come with a sandbox to protect against exploitation. X11 is one of the biggest holes in these sandbox solutions. Replacing X11 with Wayland would plug this hole. I'd argue that security is something the average user cares about.
If your web browser is compromised, that's malware running on your system right there.
A compromised web browser doesn't need X to control the rest of your system. It can usually already write all over your system and perform all sorts of other attacks, including substituting applications, paths, LD_LIBRARY_PATH, etc.. not to mention try kernel exploits and the like -- not that they'd need to on a single-user system, as they could just get your sudo password by one of the other means mentioned above, all without touching X.
Anyway, if a typical user's browser is compromised, they're already completely screwed, as they typically access their online banking and webmail through it. Once again, the attacker does not need to touch X to get access to any of that.
To me it still sounds like Wayland's security model is trying to solve a niche problem that most X users don't really suffer from -- and charging an arm and a leg for it.
> It can usually already write all over your system and perform all sorts of other attacks
Not necessarily. Properly sandboxed applications like Chromium have a seccomp filter, separate pid/user/etc namespaces and bind mounts setup to isolate themselves from the rest of the system as much as possible.
> Anyway, if a typical user's browser is compromised, they're already completely screwed
It really depends on which part of the browser is compromised. Again, Chromium has some pretty good isolation. Having one malicious website exploit a vulnerability does not necessarily mean the attacker gets access to any of the other browser data.
If the browser as a whole has not been compromised, then internally it should be able to deal with the clipboard the same what that Wayland deals with it.
For instance, only the currently focused tab should have access to the X clipboard.
Superior performance? Like when windows take a whole second to appear because the protocol is synchronous and the server is busy doing something else? :)
Wayland makes lots of things possible: multi-monitor HiDPI, touchpad gestures like pinch to zoom (just like Macs could do ages ago), touchscreen support that's actually independent of the mouse pointer instead of always dragging it along… and there's finally no goddamn screen tearing. Every frame is perfect™.
> Superior performance? Like when windows take a whole second to appear because the protocol is synchronous and the server is busy doing something else?
Might be true, never happened to me. But what about FPS in Games. X11 beats it there for me. Or what about in the most important metric of them all: Latency. In all my Tests Latncy on Wayland is always a regression, compared to X11. (I use Intel and HDxxxx era AMD Graphics, can not say anything about Nvidia)
> Wayland makes lots of things possible
That might be true. But X11 can be extended and has been extended very often (hence the messy code). One thing I need regularly, namely OpenGL pass-through via SSH, will never be possible with Wayland.
> Every frame is perfect™
To me far less important than latency. Wayland should only care about tearing when I play full screen games. When I type on the terminal I want my characters appear instantly, then I don't care about tearing at all.
On my own testing (GNOME, latest Kernel, as well as Sway temporarily) latency and FPS were better on Wayland than X11 (though only on my beefier graphics card, windows rendered on the second one had higher latency and comparatively lower FPS than expected. But I don't game on that card.
>One thing I need regularly, namely OpenGL pass-through via SSH, will never be possible with Wayland.
Correct because Wayland isn't a network-like protocol as X is (though I've had X network passthrough break or fill up a gigabit ethernet connection worth of bandwidth on more than one occasion).
If you want remote desktop on Wayland, you need a tool specifically designed for that.
It's the unix mindset after all; why have one tool (X) do everything when you can have lots of tools interact and each solves it's own little problems (Wayland + tools)?
>Wayland should only care about tearing when I play full screen games.
If you run a game on wayland you usually get control over the screen anyway when you go fullscreen, once you have exclusive control you can go tearing all you want.
Though with adaptive sync becoming more common (and already being common on laptops) the perfect frame is less costly than tearing; the display will run at the FPS you can manage (within bounds). For it to work you only need to VSync and the GPU driver handles the rest.
In my experience, Wayland has way better and smoother performance than X on adaptive sync displays.
X11 doesn't easily support multiple monitors at different DPI, which is almost essential when using a hiRes laptop with an external (also hiRes) monitor.
Window managers can implement their own extra protocols of course, but instead of X11 where everything was standardized and window managers didn't even have to think about it, there is no standard and window managers have to rewrite all the code for it themselves.
As another example, Linux doesn't have just one desktop environment, like Windows or MacOS, would you say that's an "issue", even if it's a deliberate decision?
"GNOME and KDE have dbus APIs for some (but not all) of these things, and sway has
its own IPC, and other compositors probably have similar solutions. However, they
all use different mechanisms, which means that if you are writing say, screenshot
application you either have to write a different backend for every compositor, or
choose just one or two to support.
"Something all of these types of applications have in common is they need to be able to inspect and/or modify state from other applications or the compositor itself. Which wayland's security model normally prevents. I think a major gap in wayland, is having a way for an application to run with escalated permissions so it can have access to other applications. Unfortunately, I don't have any great ideas on what that would look like."
and then, later in the thread:
"for simple things using the compositor's screen shot tool is fine. But what if I don't like the screenshot tool for my compositor of choice? My experience with the GNOME screenshot tool (granted this was pre-wayland) was that it wasn't as good as, say, shutter, which has a lot of options, let's you easily crop and edit the screenshot from inside the screenshot tool etc. And then swaygrab doesn't even (currently) have an option to capture a rectangular region."
The entire thread linked to above is worth reading.
My own takeaway is that Wayland is just way too immature to compete with X for my power-user use cases.
Luckily, Firefox supporting Wayland doesn't hurt you at all. I'm also very excited about Firefox supporting Wayland. It isn't dropping support for X11.
I have a local html page devoted to news. An entry for a specific site will see at least two urls: The main site's URL and a link to it's RSS feed.
Linking to the feed directly was a great way to bypass all the modern garbage on the home page to see a simple list of articles (not unlike HN's home page). It's borked now...
None of my RSS links render. Chromium was very bad at this but at least it rendered a few (a couple of examples below), FF64 doesn't render any (in any form):
A huge part of my ability to enjoy the web has just been destroyed.:( I'll have to test this on other browsers...
edit (update): both sample links above are working now (odd). Most others with XML, RSS, Atom extensions do not render (FF offers to open in external app or save).
I believe that the FF RSS reader is still available via extension. I am not 100% certain but I seem to recall hearing that in a podcast which covered the pending demise of standard RSS support in FF.
I know it is not what you've been doing but it may be something you'd like to consider. I also love RSS and even though there are many add-ons to use in Firefox to restore that kind of functionality, I prefer to use Thunderbird to consume RSS/Atom feeds, I've posted about it at:
I actually use The Old Reader[0] for most tech sites (including hnFrontPage and showHN). There are other sites that I'm only partially interested in or they have so much content, I don't want them in my Reader.
When I have time, I'll access the Feed Link and give the stories a bird's eye view. Also, some of these home pages are a nightmare in the Times Square sense of the word.
The Old Reader also keeps the the Feed Link accessible. Sometimes I'll hit the [mark all as read] but later on, I might go back and look at the day's listings for a particular site. I'm surprised how often I do this for some sites (mostly to reread an article or follow up on a comment I made). That flexibility is lost now.
Also, I don't subscribe to general news sites. The amount of articles would be overwhelming. News sites with RSS Feed Links make them manageable. I've essentially lost this - so I'll either have to access their obnoxious home pages (with anti-trackers fully loaded) or find other means.
I used to go local on my feeds... and while I avoid the cloud for most things, feed listings feel very natural there (also they don't take up local storage).
It's workable but I'm a bit annoyed that an application built on rendering (simple) tags (rq'd little/zero work to maintain) decides that things associated with RSS are going to be killed off (maybe??... in favor of their own news sources - which require much more work to maintain).
Why not use a feed reader which is designed and optimized for that task? I like Newsblur.com (aka https://github.com/samuelclay/NewsBlur) but there are tons of great desktop apps which do a much better job than Firefox ever did.
Another vote for newsblur. I plan to self-host, but until I do, Sam hosts it for me. (... and I'll keep playing for premium even when I do self host, because shiloh needs to eat too :)
Interesting. I am ux designer and i never thought people care about this or even realize there is difference. I mean actually quite opposite lot of people i know were confused from the movements first time this feature landed in safari.
Anyway surely this is not a showstopper. I mean it is not functional in any way.
Scrollbars that auto-hide and bounce scrolling are standard behavior for any macOS application.
Apps that don't do this both look and feel weird.
Maybe not a showstopper if Firefox were offering unavailable-anywhere-else behavior, but it's completely natural and predicable that users will migrate to one of the other two major browsers that care enough to make themselves fit in w/ the system they are running on.
Well Firefox is actually offering "unavailable-anywhere-else behavior" - it's free software that does not require you to log in and send private browsing data to google. This is the case for anyone having google account - which is almost everyone.
(Also called rubber-band scroll or elastic-scrolling)
macOS feature adopted from iOS where when you try to scroll past the end of a document, rather than just doing nothing, it sort of stretches/bounces/rubber-bands past the bounds and then snaps back.
It's nice because (1) it feels believable and physical (2) it gives you feedback that you really are at the end of the document, rather than just the computer lagging.
> Symantec CA Distrust: Due to a history of malpractice, Firefox 64 will not trust TLS certificates issued by Symantec (including under their GeoTrust, RapidSSL, and Thawte brands). Microsoft, Google, and Apple are implementing similar measures for their respective browsers.
> Multiple tab selection: We’re excited to introduce multiple tab selection, which makes it easier to manage windows with many open tabs. Simply hold Control (Windows, Linux) or Command (macOS) and click on tabs to select them. Once selected, click and drag to move the tabs as a group — either within a given window, or out into a new window.
Offtopic for sure, but the way most places I've worked have used the terms is: "alpha" means that the developers think it's done. "beta" means QA thinks it's done. "release" means that actual user testing revealed no showstoppers.
Assuming you're on non-Windows, the message is expected and not indicative of a problem. I've pushed a patch to disable it going forward. Sorry for the noise.
The new API browser.menus.overrideContext is announced with documentation links pointing to blogs, including a personal blog page with unrelated Japanese texts and anime pictures. The official documentation (MDN) has no reference to the new features. Even the API features from FF63 (august 2018) are only have a draft of documentation (e.g. Menus.getTargetElement). Documentation is important, even more for an API. I think this pattern is worrying.
Yeah, the feature is not introduced that well. It is mostly a good feature for the extension that they are talking about, TreeStyleTab[1], which explains the feature. Piro's blogpost is actually awesome. It describes the history of the feature, and how it is used today in his extension.
However, they could stand do the documentation themselves, or at least setting up the context of the blog-post a little more.
I am not worried by the reference to the post, Piro may not have the most pretty site, but his writeups are great!
In this case, I don't care much if the blog is pretty or not and who wrote it, even if Tree Style Tabs is my main reason for using Firefox. The problem is that Firefox is relying on an external source as the main explanation of their new API. Will the URL still be right in a few months? They have no control over it.
MDN is one of the best achievements of Mozilla, so I worry when I see it is not updated with their own technologies.
As mentioned above, piro_or is the developer of the popular extension this feature was tailor-made for. I imagine it is well-documented on their site because they were closely involved in the development. I see no reason not to presume the documentation hasn't been added to the wiki yet simply because the devs were working down to the wire to get it included in this release as many users have been clamoring for it. In fact, there is a fairly detailed blog post on Mozilla's site that suggests this is the case.[1] All the worst-case assumptions about Mozilla on this site are getting tiresome.
That's the blog of the developer of Tree Style Tabs, who is presumably Japanese. I agree that it would be nice to have such information on MDN, and since MDN is a wiki, anyone here can do it if they feel strongly enough about it. The linked blog post contains a wealth of information describing how the API works, along with links to further explanatory posts.
526 comments
[ 2.9 ms ] story [ 339 ms ] threadReading the release notes:
Doesn't seem like this fixes the high CPU issue on MacOS.Maybe in another few dozen releases they'll fix it. Doesn't Mozilla realize how many people develop on MacOS? Everyone I know develops on a Mac.
(I have the same issue and I'd like to switch to Firefox)
I use Firefox exclusively and have done so for the last 2 years or so. This sounds like it could be a driver issue for specific macs. Both my macs have AMD Radeon chipsets & quad core i7s.
Anyway, I'm sure this issue is real. Bugzilla ticket numbers probably exist for it and might be more helpful than vague complaints about things being slow.
Of course some web sites are a bit unreasonably javascript heavy these days. The downside of a large screen is that pushing a lot of pixels around is not free. Usually closing any offending tabs immediately restores any cpu usage I see. I'd suggest using the new task manager thingy (page menu->more->task manager)
When I switch to the "default" scaling (1440x900 and 1280x800, respectively), it stops. Only the 15" has a discrete GPU, eliminating that as potentially causal.
The "problem" scaling is 1.5x. The default is 2x.
It seems like they are aware of the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1404042
If you have performance issues; you might want to check whether you need to blame the browser or some of your extensions.
This is a known issue, and has been around since at least v57. There are multiple Bugzilla issues on it. The cause is known. It isn't extensions. The fix is just invasive, and apparently ongoing.
The thread-parent absolutely cast a wider net than warranted, but everyone in this discussion who has experienced this problem knows exactly which one we're talking about, and the rest are all, "I've never seen a problem!" or "It's probably just extensions." Meanwhile, there's reliably a sub-thread somewhere in the discussion on nearly every article about Firefox, about this problem.
I find it profoundly ironic that you comment down-thread that "humans are very prone to confusing things which affect them personally with the general case" about a thing which you haven't personally experienced. You talk as if those of us for whom this is a 100% reproducible problem are an edge case, based AFAICT solely on your own not suffering it, coupled with your (not incorrect) beliefs about people poorly attributing performance problems in general.
That juxtaposition is really galling.
I recently switched to Brave Developer Edition [1], which now supports Chrome extensions (which I need for work/pleasure). It runs circles around Firefox and Chrome, and maintains my privacy better.
Previously it was a tradeoff of getting speed (Chrome) or maintaining privacy (Firefox). For me, Brave does better on both counts, and now that it supports extensions I'm completely sold.
1: https://brave.com/download-dev/
For pageloads Brave might do better if it blocks various stuff by default, of course.
This is one of the key differentiating factors of Brave. Maybe next time don’t lead with accusations of cognitive bias.
It's been like this for at least 2 years now on my MBP 2015.
https://pcwalton.github.io/2018/12/07/plans-for-2019.html
That said, I've thought this before and turned out to be wrong. But it looks like it might be real this time.
> Easier performance management: The new Task Manager page found at about:performance lets you see how much energy each open tab consumes and provides access to close tabs to conserve power
> Improved performance for Mac and Linux users, by enabling link time optimization (Clang LTO). (Clang LTO was enabled for Windows users in Firefox 63.)
Release Notes: https://www.mozilla.org/en-US/firefox/64.0/releasenotes/
This is pretty neat, now I'm wondering why the webex extension is having "Medium" impact when it should be doing nothing.
At least it's not Google Hangouts. That crap platform will kill any laptop battery in ~30-45 min flat and make it seem like you're rendering some 8K video.
Does this mean I need to build it myself or is the binary gonna ship this way?
https://www.zdnet.com/article/malicious-sites-abuse-11-year-... https://bugzilla.mozilla.org/show_bug.cgi?id=377496
EDIT: Dang, guess the spittle brigade is really out in force today. Anyone downvoting want to maybe respond in substance as to why they think Firefox should continue ignoring security issues that have been open since the Bush administration?
Just to check, is that sarcasm? Because having those end up the same for users who use non-default colors is a _very_ common webdev mistake...
And what do you mean by using non-default colors? User stylesheets would also include scrollbar colors anyway; do you mean just setting a background but no text color (assuming a default of black, which might not be black for the user)? Don't see how this could apply to this CSS property, since it takes two colors, you either set both or none.
It seems logical to me that if you can read the text on the web page, that is, if the web dev hasn't made the common mistake that renders the text unreadable, they will set the scrollbar colors to something of similar "quality". If you can't read the text because they use CSS badly, then the scrollbar color is the least of your worries. QED?
Generally speaking, there are a lot of "common webdev mistakes", like using the giant images and scaling them down, having text and background color very close together... but we don't take that away just because some abuse it, so resisting more flexibility on those grounds doesn't strike me as so "obvious" as people seem to agree it is. If you can allow websites to hide the mouse cursor, I don't think the web will break because of this CSS property. If you don't want to see it on any page, override it in your user stylesheet, done.
I object to this as well, but that's a battle that was lost a long time ago.
Yes, I do see the usefulness of being able to do all of those things, but in practice, I don't appreciate it when it's done. I'm not saying that it's abusive (and I'm not talking about egregious misuse of these abilities), I'm just saying that I personally dislike it when sites do this sort of thing.
I fear that I've come off as too militant on these issues -- as a web dev, you should do what you deem best. As a user, if your choices are too annoying to me, I'll just avoid your site.
I think this whole thing just plays into a personal issue I have over the web these days... from a usability and aesthetic standpoint, the web has been noticeably declining for me over the past few years.
That I can certainly agree with. I also think users should be able to override and customize things... ideally, everybody gets more options? And user agents should absolutely be user agents, instead of brochure displays.
While design may be somewhat subjective, I also think websites are getting worse. If that's a "personal issue", we both have it :D Just the last one I just looked at, that made me think "why? who is this for?"
https://www.opensuse.org/
vs.
https://web.archive.org/web/20081210082207/http://www.opensu...
I just think marketing (and mobile?) play a much larger role in the downfall of the web and the rise of generic copy drowning in padding, than all the stuff we can do with CSS.
Example from Codepen: https://vgy.me/IBmcUz.png
I would, reader modes are a godsend that revert the web back to how it should have always been, with the client controlling the text and background color in a way consistent with the rest of the system.
Content display should be up to the user, not the designer.
https://dbaron.org/css/user/
I never used them, but Opera had a few preset user stylesheets right there in the "view" menu at the top of the window, that was neat. One was "C64" IIRC. Silly, but neat ^^
https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative...
If styleesheets could have placeholders for some system colors (maybe even fonts?), that could be something.. turn nightmode on/off, or just generally change colors, and all programs and all websites fade! I would actually love "having to" make 3 stylesheets, one super fancy one, a print stylesheet, and a "system colors" one. Or don't even stop with colors, do it like Magic User Interface on the Amiga, let the user configure how they want all sorts of input and information fields to be formatted and behave... some people want material design (they're wrong of course, but if they must be wrong, I want them to at least be wrong and happy, rather than wrong and unhappy), others want gradients and bevels and shadows everywhere, let everybody set it how they want. Some people want lots of padding, others want tight padding and negative linespacing and tiny fonts, etc.
Awww, now I'm super excited about something that doesn't exist... I can taste it, it would be so awesome! This is the wrong timeline :/
As such, they should be off limits to web designer's whims.
As an aside, my experience with web sites over the years (particularly recently) doesn't exactly give me a great deal of confidence that they would make appropriate choices for the appearance of these controls.
Depends on the browser, but e.g. text area colors can be styled anyway (and therefore made unusable, how irresponsible that CSS allows for this), and whether scrollbars show up in the first place is CSS, too. You can override that with user stylesheets if you want, but no need to hardcode that for everybody.
> doesn't exactly give me a great deal of confidence that they would make appropriate choices for the appearance of these controls.
You're now the third person to say this, and the second to do so while ignoring what I responded to that point, so again:
If you can't read the text, why do you care about the scrollbar? If you can read the text, why do you worry about the scrollbar? In what conceivable practical scenario do you gain anything? The very same people who picked all the other colors might also color the scrollbar, but how is going to make a default scrollbar make an otherwise unusable site usable?
We can already hide scrollbars, but coloring them differently, that's a problem? I don't buy it, as they say. How is an ugly scrollbar, or one that uses the same color twice and is unusable that way, worse than none?
Because it's not really about being able to read the text. It's about usability and my preference for appearance.
"How is an ugly scrollbar, or one that uses the same color twice and is unusable that way, worse than none?"
It's not. None is worse, by far.
And I say that as someone who's tweaked scrollbars but only in userContent / userChrome configs.
https://codepen.io/dredmorbius/pen/QwXBEO
I do NOT want you to try and make my UI look "pretty" (or whatever). I want it to be FUNCTIONAL.
https://bugzilla.mozilla.org/show_bug.cgi?id=1463423
chrome://flags/#top-chrome-md
I've got mine set to 'Normal'.
I really, REALLY hate that they're killing this feature, but this addon promises to restore it: https://www.ghacks.net/2018/07/30/livemarks-restores-live-bo...
Edit: here's the official GitHub: https://github.com/nt1m/livemarks/
Mozilla did the same with tab groups, then the addon was abandoned. The replacement that is compatible with the new form of extension isn't able to unload the tabs, just hide them, which undoes most of the performance benefits.
[abraham simpson voice] It'll happen to you too! [/abraham simpson voice] /jk
Wouldn't that indicate that the extension was not that widely used, and as such Mozilla were correct in removing it from the central codebase?
At Mozzila they need to prioritize many different things and I can understand how a constant push to make the browser leaner is foundamental. (especially in cases like RSS feeds)
I don't think most people even knew it was there.
I can't imagine Mozilla crippling the addon API to the point where it can't grab data off an RSS feed and display it.
I don't buy that. It's my browser running on my computer, it's my choice whose code I choose to run on it.
If, say, emacs or vi had this kind of handholding, neither one would be much more than a text editor.
I believe this information is out of date. Firefox 58 brought extension developers the ability to unload tabs: https://bugzilla.mozilla.org/show_bug.cgi?id=1322485
And Totally Not Panorama takes advantage: https://addons.mozilla.org/en-GB/firefox/addon/basic-panoram...
I wish tab handling had a first-class API in Firefox, so that different tab managers could interact with the default tab menu, etc.
Firefox 64 introduces an entirely new API, browser.menus.overrideContext, which allows complete customization of the context menu shown within add-on content like sidebars, popups, etc.
This is illustrated right in the post by my favorite pain point, the Tree Stye Tab custom tab menu mixing with the regular tab menu.
Finally!
Yes, but I don't really want tree-styled tabs, I want tab groups :P The interface is vastly different.
.. now if only Google had used that to notice the things I like about Inbox and keep them :-(
Maybe they are also in the wrong if the telemetry is excessive, but the alternative is to never deprecate any feature ever.
Better than keep removing features and reasons to use Firefox from some of their loyalest users, even if they are a minority. User retention seems Mozilla's largest issue at the moment now they're down under 10%.
Also, 0.01% of a big number is still a big number, and given the state of the feature, that number is likely to include a lot of long-time users.
When resources are constrained you have to make decisions about what features you'll continue to develop and which to cut out. Live bookmarks was cut out. Mozilla devs have also mentioned that this feature is ancient code and would have required a lot of coding effort to bring up to date.
I'm sure if you were to invest the time to reimplement live bookmarks with modern code and with the internal restructuring in the browser in mind and you'd volunteer to maintain it and fix all filed bugs, they'd accept it.
They removed the visibility years ago, then progressive updates made them ever less visible, including hiding then removing RSS notification. Once the first step was taken, the route to removal was set, including the telemetry figures.
If they were as visible as pocket, perhaps as visible as pocket stories on new tabs, usage would be hugely higher.
https://github.com/nt1m/livemarks/issues/17
Still, this update felt particularly user hostile. My user experience was:
- I'm in the middle of browsing and open a tab to do a search, but the new tab shows the "Firefox needs to restart because updates are more important than you!“ page.
- I'm forced to restart. Manually, since the automatic restart is probably broken on my system. Tab state in some SPA tabs are lost.
- Now I have to migrate my live bookmarks. They converted themselves to regular bookmarks- I have to right click and delete those one by one. Then I install Livemarks, import the exported bookmarks data, and then drag those one by one to my bookmarks toolbar.
I'm half considering Chrome. If Firefox is going to be like this, why bother? Might as well start the Chrome dominance and stagnation part of the browser cycle.
I would like these features to be standardised to hands-off-my-fricking-scrollbars.
I’m fed up with impossible-to-grab 1px-wide scrollbars because “everyone has trackpads”. No, they don’t.
A browser-wide scrollbar styling system, able to be opted into by use of particular CSS, doesn’t imply anything about whether we are talking about just one scroll bar or all of them.
I also disagree about native controls not always being the best solution when it comes to scrolling. We all know how annoying it is when a page jacks scrolling; it’s a usability nightmare that makes pages’ scroll behaviour harder to predict. We don’t need to add to the usability issues by letting one of the most fundamental pieces of chrome in a web browser get jacked even further than the already impermissible state.
Don't most mice have scrolling as well? It's not about trackpads.
Long story short, stop fscking with accessibility. If your js code or libraries handles ANY input events, you'd better watch yourself because you're venturing into specialized-interface-by-and-for-assholes-land.
Imagine you cmd + F a phrase and there are 200 responses separated into like 4 chunks of a document. It can be useful to scroll to the start of each chunk to get the context of them.
I realize the benefits of the Overlay Scroll Bar to the majority of users who have scroll-wheels. But it sure would be nice if there was an easy way to revert back to the Normal Scroll Bar ("Classic" scroll bar?). You know, the wide bar that scrolls down exactly one page-length if you click outside of the bar? I've spent plenty of time Googling and in "about:config" and exporting environment variables like GTK_OVERLAY_SCROLLING=0 to no avail.
But not all.
[0] http://kb.mozillazine.org/User.js_file
One thing I like about the Firefox (Gtk?) scrollbar is that it finally removed (a few version ago already) the "Click on it somewhere, but it doesn't move there but just acts like PgDown/Up", i.e. the non-warping to the exact click position but just inching towards it. This is completely unnecessary in the time of wheels and touchpads and I already miss it everywhere else.
It is completely necessary for me to have “move one page up on click.”
Definitely no: If I have a hand on the mouse I surely don't want to lift it and hunt for the PgUp or PgDown just to move one page up or down. And no, I don't want to go "there" if it's actually "somewhere" in the middle of whatever, if I just want to see the previous or the next page. Going "there" is much less frequent operation than moving to the next or the previous page.
"Most"? Where did you get that idea? "Most gaming mice" or what? Most of the users aren't gamers.
> that means a PgDown button (I guess it is mostly that direction) on the mouse is missing.
Of course is missing: "normal" (as in the most common) mice have only 2 buttons and the scroll wheel.
The scroll wheel never moves one page up (or down), but just some small number of lines, so the most common operation is then impossible for the most of the users just because a developer (who probably even "lives" in his terminal for most of the time, never lifting the both hands from the middle of the keyboard) thinks that everybody has exactly the gear that he has.
- left click - page up/down
- middle click - go directly to this point.
Moving one of these to the other is confusing and a loss of useful functionality. Reminds me of "chesterton's fence."
For most longer texts, I hate "click to here" on the scrollbars. It's impossible to get it right. Them working as pgup/down makes much more sense.
A handful of people love it, most think it's a bug. It's particularly bad if you're using a trackpad.
I would theorize that it's not a well known complaint because most people move on quickly and just assume their computer is buggy.
If you're uncomfortable with the user realizing the game is a browser game, why did you make it in a browser?
Customising UI elements is a usability antipattern.
Per [1], predictability and familiarity are key in creating usable interfaces. Making things look nice "because you can" doesn't necessarily mean you should.
> When designing your interface, try to be consistent and predictable in your choice of interface elements. Whether they are aware of it or not, users have become familiar with elements acting in a certain way, so choosing to adopt those elements when appropriate will help with task completion, efficiency, and satisfaction.
[1] https://www.usability.gov/how-to-and-tools/methods/user-inte...
Sadly the world has gone the other way and basically ditched the whole concept of native widgets and consistent look and feel.
> Does this principal apply to X for y?
In a vacuum, yes it's a principal.
In reality, while it's an antipattern it doesn't mean you should be afraid let alone disallowed the ability to exercise good judgement and make a call.
Full window, emersive games are the perfect example of UI elements like buttons that should probably be reskinned - wisely. I say wisely because you can still reskin buttons in a way that affords familiarity you can also reskin them in a way that makes them abhorrent.
A converse example is windows based skinnable hardware interface software like MSI afterburner and the like. That sort of thing is absolute unthought, untested garbage.
For website buttons I think the ship has sailed and the default elements actually look alien.
In fact a lot of CSS frameworks improve net usability from defaults anyway.
Now, is it an antipattern to use them? In essence yes, but considering everything no. Caution, many css frameworks have UX issues and you need to make a judgement in your evaluation about which features to use. I like to see how their autocomplete / dropdown features work it's usually a good litmus test because those things are basically impossible to do right.
And this why we have UX people.
It is the marriage and trade off of usability/hci and designers to create a usability experience that delights.
Though things still tend to lean toward design first approaches. Which aren't incorrect approaches but do tend to lack emphasis on circling back to fix usability later.
I think website internals are widely debatable but do have norms you must consider.
I draw the line at breaking out of the window sandbox and altering browser UI. It assumes all browsers work the same and creates a dependency on the browser for a shared experience.
An inconsequential example: setting browser ui color on mobile version of Chrome. Now your whole website design feels very native and is reasoned about with that native feel. That can them lead to inconsistent design assumptions being made on the desktop. Maybe your color selection clashes badly with the desktop grey.
Like I said, inconsequential, but might illustrate why messing with it might be a bad idea.
The other big reason I throw down at the browser window line is accessibility. Messing with things like button sizing / scrollbar sizing and things wrecks absolute havoc on these users. They also make English centric assumptions about designs that are almost always wrong eventually.
Castle of the Winds, Windows 3.11.
I remember having a lot of fun playing Stars! as a child: https://www.mobygames.com/game/stars
The work around was to use JavaScript, just to make it work on Firefox.
It can now be implemented in CSS, which makes it really easy for you to disable or change your preference as well putting the responsibility of style on CSS and not some annoying JavaScript.
I mean, other than the fact all "modern" websites suck now too.
Progress?
Edit: if you don't unselect and close a tab you lose all your pins...
If you'd like to use KDE file selectors in a non-DE setup, you'll need to get `xdg-desktop-portal-kde` working.
To test it once you could execute:
GTK_USE_PORTAL=1 firefox
If you want a more persistent solution you could add
export GTK_USE_PORTAL=1
to your .profile or /etc/profile (if you want it for all system users)
Disclaimer: I am a Linux user since >20 years, using XMonad window manager on Ubuntu 16.04 at the moment.
¹ https://bugzilla.mozilla.org/show_bug.cgi?id=635134
² https://wiki.mozilla.org/Release_Management/Calendar
From the linked-to-post, it lacks:
* Programmatic output configuration (xrandr, arandr, etc.)
* CLI clipboard access (xsel, xclip)
* Third party app launcher/window switcher (rofi, dmenu, albert, docky).
* Clipboard managers (parcellite, klipper, Gpaste, clipman, etc.)
* Third party screen shot/capture/share (shutter, OBS, ffmpeg, import, peek, scrot, VNC, etc.)
* Color picker (gpick, gcolor3, kcolorchooser)
* xdotool
Lack of Wayland versions of these apps is a deal breakers for me, and I'm going to avoid Wayland until it gets them.
[1] - https://old.reddit.com/r/wayland/comments/85q78y/why_im_not_...
Why do we need Wayland?
Also, when I run X just for myself on my own laptop, what security issues do I have to worry about with X that I don't have to worry about with Wayland?
With regards to security, the main issue is that X11 provides no isolation between applications, allowing them to listen to keystrokes and the clipboard at all times. With Wayland, only focused applications have this access.
Currently I'm using an old, slow laptop, with a graphics card integrated in to the motherboard. Nothing special. But I don't do any demanding graphics processing on it. I just watch movies and use web browsers and a terminal. I don't play graphically intense games on it.
"With regards to security, the main issue is that X11 provides no isolation between applications, allowing them to listen to keystrokes and the"
I don't see why this should concern me or 90% of X users, because if any malware manages to run on our systems it'll already have full control over them without needing to resort to any kind of keystroke sniffing in X.
I'm struggling to think of a scenario where malware's running on the same machine with access to a single X session, which doesn't already have full control over the account whose keystrokes they'd be presumably sniffing. They could just substitute their own malware versions of web browsers, shells, editors, or whatever other software the user uses and sniff keystrokes in there, without needing to touch X.
Not that it hurts to have more isolation than you get in X, but I'd need a lot more convincing for me to give up the convenience I already enjoy with X.
Can someone paint me a realistic, relatively common threat scenario where not having Wayland's isolation would actually present a serious security risk?
A compromised web browser doesn't need X to control the rest of your system. It can usually already write all over your system and perform all sorts of other attacks, including substituting applications, paths, LD_LIBRARY_PATH, etc.. not to mention try kernel exploits and the like -- not that they'd need to on a single-user system, as they could just get your sudo password by one of the other means mentioned above, all without touching X.
Anyway, if a typical user's browser is compromised, they're already completely screwed, as they typically access their online banking and webmail through it. Once again, the attacker does not need to touch X to get access to any of that.
To me it still sounds like Wayland's security model is trying to solve a niche problem that most X users don't really suffer from -- and charging an arm and a leg for it.
Not necessarily. Properly sandboxed applications like Chromium have a seccomp filter, separate pid/user/etc namespaces and bind mounts setup to isolate themselves from the rest of the system as much as possible.
> Anyway, if a typical user's browser is compromised, they're already completely screwed
It really depends on which part of the browser is compromised. Again, Chromium has some pretty good isolation. Having one malicious website exploit a vulnerability does not necessarily mean the attacker gets access to any of the other browser data.
For instance, only the currently focused tab should have access to the X clipboard.
This is a bit naive. Browsers execute malicious javascript on your system all the time. A V8 sandbox escape is worth retirement money for a reason.
Wayland makes lots of things possible: multi-monitor HiDPI, touchpad gestures like pinch to zoom (just like Macs could do ages ago), touchscreen support that's actually independent of the mouse pointer instead of always dragging it along… and there's finally no goddamn screen tearing. Every frame is perfect™.
Might be true, never happened to me. But what about FPS in Games. X11 beats it there for me. Or what about in the most important metric of them all: Latency. In all my Tests Latncy on Wayland is always a regression, compared to X11. (I use Intel and HDxxxx era AMD Graphics, can not say anything about Nvidia)
> Wayland makes lots of things possible
That might be true. But X11 can be extended and has been extended very often (hence the messy code). One thing I need regularly, namely OpenGL pass-through via SSH, will never be possible with Wayland.
> Every frame is perfect™
To me far less important than latency. Wayland should only care about tearing when I play full screen games. When I type on the terminal I want my characters appear instantly, then I don't care about tearing at all.
On my own testing (GNOME, latest Kernel, as well as Sway temporarily) latency and FPS were better on Wayland than X11 (though only on my beefier graphics card, windows rendered on the second one had higher latency and comparatively lower FPS than expected. But I don't game on that card.
>One thing I need regularly, namely OpenGL pass-through via SSH, will never be possible with Wayland.
Correct because Wayland isn't a network-like protocol as X is (though I've had X network passthrough break or fill up a gigabit ethernet connection worth of bandwidth on more than one occasion).
If you want remote desktop on Wayland, you need a tool specifically designed for that.
It's the unix mindset after all; why have one tool (X) do everything when you can have lots of tools interact and each solves it's own little problems (Wayland + tools)?
>Wayland should only care about tearing when I play full screen games.
If you run a game on wayland you usually get control over the screen anyway when you go fullscreen, once you have exclusive control you can go tearing all you want.
Though with adaptive sync becoming more common (and already being common on laptops) the perfect frame is less costly than tearing; the display will run at the FPS you can manage (within bounds). For it to work you only need to VSync and the GPU driver handles the rest.
In my experience, Wayland has way better and smoother performance than X on adaptive sync displays.
Every frame is great. If a frame is missing, ### gets quite irate.
With Gnome et al you are most certainly in high latency hell on X11.
* Programmatic output configuration
swaymsg -t get_outputs # get displays
swaymsg output DP-1 pos 0 0 res 1920x1080 # set displays
* CLI clipboard access
swaymsg -t get_clipboard
* Third party app launcher/window switcher
I use gnome-panel with Xwayland, but better than nothing
* Third party screen shot/capture/share
https://github.com/foss-project/green-recorder
* Color picker (gpick, gcolor3, kcolorchooser)
Sorry, no options here yet, but it can be done
* xdotool
swaymsg [title="Top Panel"] floating enable, resize set width 2560 px height 32 px, move position 0 -38
Window managers can implement their own extra protocols of course, but instead of X11 where everything was standardized and window managers didn't even have to think about it, there is no standard and window managers have to rewrite all the code for it themselves.
It's not an "issue". It's a design decision.
As another example, Linux doesn't have just one desktop environment, like Windows or MacOS, would you say that's an "issue", even if it's a deliberate decision?
"GNOME and KDE have dbus APIs for some (but not all) of these things, and sway has its own IPC, and other compositors probably have similar solutions. However, they all use different mechanisms, which means that if you are writing say, screenshot application you either have to write a different backend for every compositor, or choose just one or two to support.
"Something all of these types of applications have in common is they need to be able to inspect and/or modify state from other applications or the compositor itself. Which wayland's security model normally prevents. I think a major gap in wayland, is having a way for an application to run with escalated permissions so it can have access to other applications. Unfortunately, I don't have any great ideas on what that would look like."
and then, later in the thread:
"for simple things using the compositor's screen shot tool is fine. But what if I don't like the screenshot tool for my compositor of choice? My experience with the GNOME screenshot tool (granted this was pre-wayland) was that it wasn't as good as, say, shutter, which has a lot of options, let's you easily crop and edit the screenshot from inside the screenshot tool etc. And then swaygrab doesn't even (currently) have an option to capture a rectangular region."
The entire thread linked to above is worth reading.
My own takeaway is that Wayland is just way too immature to compete with X for my power-user use cases.
It might be ok for users with simple needs.
https://bugzilla.mozilla.org/show_bug.cgi?id=1512416 https://bugzilla.mozilla.org/show_bug.cgi?id=1509740
I have a local html page devoted to news. An entry for a specific site will see at least two urls: The main site's URL and a link to it's RSS feed.
Linking to the feed directly was a great way to bypass all the modern garbage on the home page to see a simple list of articles (not unlike HN's home page). It's borked now...
None of my RSS links render. Chromium was very bad at this but at least it rendered a few (a couple of examples below), FF64 doesn't render any (in any form):
http://feeds.arstechnica.com/arstechnica/index
https://feeds.feedburner.com/ItsFoss
A huge part of my ability to enjoy the web has just been destroyed.:( I'll have to test this on other browsers...
edit (update): both sample links above are working now (odd). Most others with XML, RSS, Atom extensions do not render (FF offers to open in external app or save).
http://andregarzia.com/2018/11/reading-blogs-with-thunderbir...
Since Thunderbird is also my email client, it becomes a very pleasant experience of catching my email, my newsletters and my blogs in the same client.
I actually use The Old Reader[0] for most tech sites (including hnFrontPage and showHN). There are other sites that I'm only partially interested in or they have so much content, I don't want them in my Reader.
When I have time, I'll access the Feed Link and give the stories a bird's eye view. Also, some of these home pages are a nightmare in the Times Square sense of the word.
The Old Reader also keeps the the Feed Link accessible. Sometimes I'll hit the [mark all as read] but later on, I might go back and look at the day's listings for a particular site. I'm surprised how often I do this for some sites (mostly to reread an article or follow up on a comment I made). That flexibility is lost now.
Also, I don't subscribe to general news sites. The amount of articles would be overwhelming. News sites with RSS Feed Links make them manageable. I've essentially lost this - so I'll either have to access their obnoxious home pages (with anti-trackers fully loaded) or find other means.
I used to go local on my feeds... and while I avoid the cloud for most things, feed listings feel very natural there (also they don't take up local storage).
It's workable but I'm a bit annoyed that an application built on rendering (simple) tags (rq'd little/zero work to maintain) decides that things associated with RSS are going to be killed off (maybe??... in favor of their own news sources - which require much more work to maintain).
[0] https://theoldreader.com/
Recently switched to Miniflux: https://miniflux.app which is much better for my needs. Small efficient Go app that works great with a PWA on mobile.
Folks, the UI look and feel stuff really matters. You can't treat a platform like a second-class citizen and hope to gain widespread adoption.
Anyway surely this is not a showstopper. I mean it is not functional in any way.
Apps that don't do this both look and feel weird.
Maybe not a showstopper if Firefox were offering unavailable-anywhere-else behavior, but it's completely natural and predicable that users will migrate to one of the other two major browsers that care enough to make themselves fit in w/ the system they are running on.
^^^ This attitude sucks!
UX is everything if you want your software to be used by the masses.
I despise it and would get frustrated at web sites that use it.
macOS feature adopted from iOS where when you try to scroll past the end of a document, rather than just doing nothing, it sort of stretches/bounces/rubber-bands past the bounds and then snaps back.
It's nice because (1) it feels believable and physical (2) it gives you feedback that you really are at the end of the document, rather than just the computer lagging.
Yes, the feedback is useful, though I'd never really realised that until now. Thanks.
> Multiple tab selection: We’re excited to introduce multiple tab selection, which makes it easier to manage windows with many open tabs. Simply hold Control (Windows, Linux) or Command (macOS) and click on tabs to select them. Once selected, click and drag to move the tabs as a group — either within a given window, or out into a new window.
Does anyone know why that error is showing up?
If it's not finished it's alpha.
Beta is pretty much just used as "buyer beware" nowadays, like a disclaimer "we take no responsibility for our bugs".
Looking at https://searchfox.org/mozilla-central/rev/adcc169dcf58c2e45b... it looks like that error means the disk cache was not created.
So either get_cache_path_from_prof_path failed to return a path or create_dir_all failed.
I haven't dug through more details, but I'm pretty sure the shader cache code there is new and am not at all sure it's completely hooked up yet.
Assuming you're on non-Windows, the message is expected and not indicative of a problem. I've pushed a patch to disable it going forward. Sorry for the noise.
However, they could stand do the documentation themselves, or at least setting up the context of the blog-post a little more.
I am not worried by the reference to the post, Piro may not have the most pretty site, but his writeups are great!
[1]: https://github.com/piroor/treestyletab
MDN is one of the best achievements of Mozilla, so I worry when I see it is not updated with their own technologies.
1. https://blog.mozilla.org/addons/2018/11/08/extensions-in-fir...