As someone who used to be involved in the decision to not implement native context menus, and did a bunch of work on the non-native ones, I want to try to explain why this took a long time.
It has nothing to do with engineering resources, and we always wanted native context menus, but they were not customizable enough to meet the perceived needs of web, XUL, and extension developers at the time. People expected to be able to change colors and layout with CSS, for example. The native APIs put heavy limitations on what you could do with a native context menu and it was just not compatible with the expectations of people building against the rendering engine at the time.
There was some discussion of switching back and forth between native and non-native menus based on styling, but that got complicated quickly and it wasn't thought to be worthwhile.
It sounds like perceived needs have changed, and maybe the native APIs allow for bit more flexibility now. Glad it's happening, excited to see how well it works!
Thanks for the explanation. As a user I very much prefer native widgets, as non-native ones always break expectations in subtle and infuriating ways, but it is interesting to see the reasoning behind this type of decision.
The fact the modern UI design has become as homogeneous as it is nowadays is a blessing that's hard to appreciate sometimes. I have to admit I still miss the early to mid 2000s era when customisation was more or less expected of every application.
I don't ever want to go back to the "Kai's Power Tools" era of UI design. Computers don't excite me, they are a tool to get things done, and consistancy makes every application easier to learn. Granted, I know I'm probably in the minority, because custom UI widgets are commonplace in mobile app design.
So I thought a little in why that is, and I realised the constant needless worthless churn on every part of "UI" from every corner of OS and application has made discovery impossible, especially discovery on my terms. A new update or UI is now terrifying rather than exciting.
The only two times I remember being excited about computers in last couple of years is when I picked up NixOS and Lisp. Now that says more about me than computers, but that's my 2c.
> Honestly kind of a depressing thing to read on "Hacker News"
Is it? For many of us, our computers are tools we use to get jobs done, so stability and predictability in function are far more valuable than something that looks pretty. Ask a carpenter if he wants glitter on their hammer, or a plumber if they need tinsel on their monkey wrench (oh and also the nut screws the opposite direction because some programmer with UX designer aspirations thought that might be neat two decades ago).
I think the implication was that this site was supposed to entertain "hacker culture" rather than "software development culture". I've also noticed a general trend from "Hacker News" to "Software Developer News", and sometimes joke about petitioning to rename the site.
Treating a computer as nothing more than a tool to get a job done is perfectly valid, but other people see general-purpose computing as a medium of self-expression and something that has value in and of itself. The latter group understandably enjoys sharing experiences with others who feel a similar way. Many came to HN hoping to find a space for that (since the site was marketed towards "hackers"), but have since been disappointed. That's probably the sentiment that the text you quoted comes from.
> Honestly kind of a depressing thing to read on "Hacker News"
I agree it is, but I also must say as of recently I agree. There hasn’t been anything in a while that’s excited me. Probably in part because I went around to learn how all the parts of the sausage are made.
I question the priorities of a developer who spends (wastes?) their time trying to dazzle me with bespoke UI. They should be focusing on dazzling me with the speed, efficiency, and reliability of the intended use of their program.
Speed, efficiency, and reliability have nothing to do with whether you use a stock or custom UI toolkit.
As an example: the GNOME file picker is computationally inefficient, ergonomically inefficient, and feature-poor. I'd much rather use some third-party developer's superior replacement (if it existed).
I'd say that a third-party replacement kit isn't bespoke UI. The GP mentioned Kai's Power Tools. If you're not familiar, have a look at how it looked. That's the kind of time-wasting drivel I'm talking about.
Love him or hate him (and I do both), Kai was all about cultivating his adulating cult of personality and dazzling everyone with his totally unique breathtakingly beautiful bespoke UIs! How can you possibly begrudge him and his fans of that simple pleasure? ;)
In the modest liner notes of one of the KPT CDROMS, Kai wrote a charming rambling story about how he was once passing through airport security, and the guard immediately recognized him as the User Interface Rock Star that he was: the guy who made Kai Power Tools and Power Goo and Bryce!
Kai's Power Goo - Classic '90s Funware! [LGR Retrospective]:
>Revisiting the mid 1990s to explore the world of gooey image manipulation from MetaTools! Kai Krause worked on some fantastically influential user interfaces too, so let's dive into all of it.
>"Now if you're like me, you must be thinking, ok, this is all well and good, sure, but who the heck is Kai? His name's on everything, so he must be special. OH HE IS! Say hello to Kai Krause. Embrace his gaze! He is an absolute legend in certain circles, not just for his software contributions, but his overall life story." [...]
>"... and now owns and resides in the 1000 year old tower near Rieneck Castle in Germany that he calls Byteburg. Oh, and along the way, he found time to work on software milestones like Poser, Bryce, Kai's Power Tools, and Kai's Super Goo, propagating what he called "Padded Cell" graphical interface design. "The interface is also, I call it the 'Padded Cell'. You just can't hurt yourself." -Kai
But all in all, it's a good thing for humanity that Kai said "Nein!" to Apple's offer to help them redesign their UI:
>read me first, Simon Jary, editor-in-chief, MacWorld, February 2000, page 5:
>When graphics guru Kai Krause was in his heyday, he once revealed to
me that Apple had asked him to help redesign the Mac's interface. It was
one of old Apple's very few pieces of good luck that Kai said "nein"
>At the time, Kai was king of the weird interface - Bryce, KPT and Goo were
all decidedly odd, leaving users with lumps of spherical rock to swivel, and
glowing orbs to fiddle with just to save a simple file. Kai's interface were fun,
in a Crystal Maze kind of way. He did show me one possible interface, where
the desktop metaphor was adapted to have more sophisticated layers -
basically, it was the standard desktop but with no filing cabinet and all
your folders and documents strewn over your screen as if you'd just turned
on a fan to full blast and aimed it at your neatly stacked paperwork.
>Bruce “Tog” Tognazzini writes about Kansei Engineering:
>»Since the year A.D. 618 the Japanese have been creating beautiful Zen gardens, environments of harmony designed to instill in their users a sense of serenity and peace. […] Every rock and tree is thoughtfully placed in patterns that are at once random and yet teeming with order. Rocks are not just strewn about; they are carefully arranged in odd-numbered groupings and sunk into the ground to give the illusion of age and stability. Waterfalls are not simply lined with interesting rocks; they are tuned to create just the right burble and plop. […]
>Kansei speakes to a totality of experience: colors, sounds, shapes, tactile sensations, and kinesthesia, as well as the personality and consistency of interactions.« [Tog96, pp. 171]
>Then Tog comes to software design:
>»Where does kansei start? Not with the hardware. Not with the software either. Kansei starts with attitude, as does quality. The original Xerox Star team had it. So did the Lisa team, and the Mac team after. All were dedicated to building a single, tightly integrated environment – a totality of experience. […]
>KPT Convolver […] is a marvelous example of kansei design. It replaces the extensive lineup of filters that graphic designers traditionally grapple with when using such tools as Photoshop with a simple, integrated, harmonious environment.
>In the past, designers have followed a process of picturing their desired end result in their mind, then applying a series of filters sequentially, without benefit of undo beyond the last-applied filter. Convolver lets users play, trying any combination of filters at will, either on their own or with the computer’s aid and advice. […] Both time and space lie at the user’s complete control.« [Tog96, pp. 174]
>Anyone who has been using Macs for at least the last ten years will surely remember Viewpoint Corporation’s products. No? Well, Viewpoint Corporation was previously MetaCreations. Still doesn’t ring a bell? Maybe MetaTools will. Or the name Kai Krause. Or, even better, the names of the software products themselves — Kai’s Power Tools, Kai’s Power Goo, Kai’s Photo Soap, Bryce, Painter, Poser… See? Now we’re talking.
>Experienced 3D professionals will appreciate the powerful controls that are included, such as surface contour definition, bumpiness, translucency, reflectivity, color, humidity, cloud attributes, alpha channels, texture generation and more.
>KPT Bryce features easy point-and-click commands and an incredible user interface that includes the Sky & Fog Palette, which governs Bryce's virtual environment; the Create Palette, which contains all the objects needed to create grounds, seas and mountains; an Edit Palette, where users select and edit all the objects created; and the Render Palette, which has all the controls specific to rendering, such as setting the size and resolutions for the final image.
>He intends to challenge everything you thought you knew about the way you use computers. 'I maintain that everything we now have will be thrown away. Every piece of software -- including my own -- will be complete and utter junk. Our children will laugh about us -- they'll be rolling on the floor in hysterics, pointing at these dinosaurs that we are using.
>'Design is a very tricky thing. You don't jump from the Model T Fort straight to the latest Mercedes -- there's a million tiny things that have to be changed. And I'm not trying to come up with lots of little ideas where afterwards you go, "Yeah, of course! It's obvious!"
>'Here's an easy one. For years we had eight character file-names on computers. Now that we have more characters, it seems ludicrous, am historical accident that it ever happened.
>'What people don't realize is that we have hundreds more ideas that are equally stupid, buried throughout the structure of software design -- from the interface to the deeper levels of how it works inside.'
I suspect "perceived needs" have changed due to the scorched earth policy Mozilla took with the old Extensions API. All extensions have had to be pretty much rewritten from scratch.
The old-style extensions were so powerful because they could put their API tentacles very deep into the rendering engine. Mozilla paid a huge price for allowing that though - it was very difficult to change the behavior of many parts of the rendering engine without breaking extensions. Much of what you'd think was just internal implementation detail was actually API surface accessible to those extensions. The workarounds added a bunch of internal complexity. It really slowed down the pace of development.
I get that some people mourn the loss of that style of extension, but dropping it was an important decision that should have happened much earlier. There were other issues with the old-style extensions (e.g. security) but making the pace of development uncompetitive should have been enough to doom it.
I wish browser extensions could pop up floating, undecorated, arbitrarily shaped, alpha-channeled popup windows, whose appearance you can define with any web technology you wanted, which could capture the mouse and keyboard to globally track input events, that would go a long way towards implementing pie menus and all kinds of other user interface widgets.
Perhaps you don't want any web page doing that without permission, but at least trusted browser extensions should be able to.
It sounds like web designers need to adjust their expectations. When they’re designing web pages, they don’t get complete control over rendering or OS controls, and just need to deal with that. The idea that a web page should be able to override things about how a contextual menu is rendered is laughable.
Thank you so much for this explanation, I always assumed it a low level to-do. Makes so much sense now, FF has loads of custom add-on menus with all sorts of UIs you don't see anywhere else in MacOS.
Closing issues automatically after a certain period of time is a disastrously stupid thing to do for a bug tracker that helps no one (not users, not reporters, not maintainers), and is actually counterproductive in systems where search excludes closed issues by default (which is most of them), because you’re certain to end up with more duplicates.
There are other types of trackers where automatic closure can be justified, but a bug tracker is not one of them.
I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice.
1000% this. The lodash library for Javascript had the authoritarian dictatorship extreme version of this for the longest time.
Any issue was immediately closed and only closed issues would be reopened if enough people gave said closed issue enough thumbs up (and "enough" wasn't even defined). And of course, this process wasn't explained anywhere except in replies to closed issues.
The obvious problem with this was that no issues were ever acted upon ever because no one ever looked at closed issues, because why would they?
I had created a proposal for a new function to be added that was and still is sorely missing. After it was closed and a long discussion ensued between many devs, I gave up and a year later I simply replied that I retract the proposal due to the ridiculous policy of actively being hostile to users. The maintainer deleted the whole issue and along with it all proof of their hostility and hypocrisy.
It was then that I decided I would boycott lodash and simply use better libraries in my projects now like Ramda, which is actually OSS. Looks like lodash is now no longer maintained and has hundreds of tickets open after the hostile maintainer (and it's not hard to guess who from looking at the commit counts) appears to have stopped maintaining it.
Funny how that works, closing tickets constantly ensures no one will want to help, and then the maintainers feel overwhelmed because they are doing it alone.
Basically closing issues is an awful practice that helps no one, as you say.
I never understood how people used lodash. Basically every function can be copied and just inserted into ones own codebase and you have one less dependency, which is very pleasant. And they are all so simple that there will never be a problem.
Disclaimer: I am not a security expert! This is my layman's attempt at mentioning a common vulnerability too many programs have but not enough knowledge is spread about it. It's easy enough to mitigate in most apps but I don't think most do.
I know this isn't directly related, however one of the vulnerabilities is prototype pollution [0], a deceptively simple technique that I think so many apps are vulnerable to. It goes like the following:
- Get an application to serialize or take `__proto__`, `constructor` or `prototype` as an input so it's a key on a JS Object
- Serialize its value to something nasty, like `'{"auth": {"name": "user", "password": "pwd"}, "message": { "text": "", "__proto__": {"canDelete": true}}}'` [1]
This high jacks the prototype of the object and adding those specified properties. If you do things like deep merging of objects on data, you are susceptible to this without the proper guards in hydration / rehydration. The mitigation is simple: don't allow objects to have `constructor`, `prototype`, or `__proto__`. You can delete them by customizing JSON.parse (by passing a reviver [2]) or using something like `mergeWith` to skip these keys
A similar vulnerability exists with `constructor` and `prototype` as well [3]
A prototype can only be modified by code that is actually being run. If you can get someone else's application to run code under your control, you've already won.
The security risk is you accept a JSON object from an API, that object gets merged with some set of defaults, oops turns out that object was specifically crafted to override the global __proto__ with some way of escalating privileges ({__proto__: {_isAdmin: true}}) and now you're owned.
It requires some knowledge of the inner workings of the system (in the above, you'd have to know that the auth provider checks for a cached `isAdmin` prop on some object before executing the authentication routine to generate it). But if your system is designed to only be secure if no-one knows the inner workings, you're probably owned anyways.
Don't forget that Lodash was basically JDalton's rip of Underscore.js. There used to be a mention of it, since the selling point was benchmarks. Now, I don't see any mention of Underscore...
Lodash as an npm module is out of control, file-size wise, and I'm not sure I'm really getting anything for it, other than once a year having to make sure we don't have ten copies of it that can't be deduped (Currently it's occupying 29MB of disk space on my production machines)
Not sure I'd call it a "rip", "ripping" for me is associated with "ripping media" which is copying video/music/data from CDs to local hardware. Lodash is more of a re-implementation of a MIT library, not something that should be shameful.
As I remember it, Lodash biggest difference was its modular approach also, not all about performance. Lodash also addressed some inconsistencies in Underscore.js.
Yeah, that's my understanding as well, from "ripped me off", implying stealing or something negative.
Having the (almost) same API surface as another MIT library is hardly a "ripoff" but a re-implementation.
Edit: since new evidence has come forward (https://news.ycombinator.com/item?id=27275379) I think we can all agree that Lodash is a fork of Underscore.js, nothing more and nothing else.
Most forks mention their origins somewhere in their bio. I'd still call it a rip considering no credit is being given at all. Why should I need to dig into the Git history to find out the creative origin of Lodash?
The license file reads: Based on Underscore.js, copyright Jeremy Ashkenas,
DocumentCloud and Investigative Reporters & Editors <http://underscorejs.org/>
If they were giving "no credit at all", they would be in violation of the MIT license.
> Most forks mention their origins somewhere in their bio
Ok, does that make forks who don't mention where they forked from rips? Huge leap in logic.
> Why should I need to dig into the Git history to find out the creative origin of Lodash?
Well, if you're interested in the origin you either look for information available in threads like this, where other people dig or you dig yourself. Not sure what the problem is. Someone published a library under MIT, another person forked that library and created a new one, also under MIT, and somehow the fork is now a rip? Give me a break
Allowed or legal doesn't imply couth. As far as I can tell, Lodash no longer mentions Underscore anywhere. This seems wrong..as if one wants to look more original than one actually is.
I have no qualms with forks or reimplementations (ie. Android - Java.) I actively support the paradigm.
But in this case, it's pretty shitty to try to erase all evidence of said inspiration. Most forks and reimplementations don't do that. They pay homage to their origin with at least a shout out.
I don't think Lodash ever "credited" Underscore.js for it's origin. Lodash used to have a "compat" version that promised to work the same as Underscore.js but with better performance, but I think that's about it.
After some digging, it seems like the Lodash website stopped mentioning Underscore.js around 2015 sometime, but even before that, it never had "evidence of said inspiration" as claimed by you.
>A tear-off menu allows users to move a menu around the screen like a window. Tear-off menus save desktop space because the user can place them on top of a document or move them to a convenient position. If you implement a tear-off menu rather than a fixed palette in a window, you allow the user to have a larger workspace in document windows. Users can also choose to leave the menu in the menu bar, or tear it off and close it when necessary. Tear-off menus give the user more flexibility than fixed palettes do.
You could try to look on in from another perspective.
The library is free and worked on by maintainers in a spare time from main duties (not talking here about lodash specifically).
Maintainers don't own you any support nor obliged to work the way you may think they should.
I would say that it's great that we have many tools and should give more respect to maintainers which basically save you a ton of resources and maximum they ask for is to follow the established processes.
The hostile and deceptive attitude of the maintainer. If they honestly admitted that they didn't give a crap about bug reports, or even just didn't bother setting up any system for recieving them, that would disappointing, but achempion's comment would cover the situation nicely. The problem (assuming the previously stated facts are accurate) is they actively set up a system to solicit and recieve bug reports, and then systematically sabotaged and neglected that system when people tried to actually report bugs.
I feel like we could have the same conversation about the Docker folks and so this feels more like a popularity contest than an objective conversation.
I've lost count of the number of tickets that have been raised that has no information, or is not reproducible, or something else. When I then ask for more information, or something else, they never reply. I've no incentive to keep such tickets open.
So I set up stale bot and auto-close the tickets. Individuals can come and re-open if it happens to them, or more information is added.
Now I do agree, if it is a genuine issue, then it shouldn't be closed until it is sorted out it. So you can set up stale bot to ignore labelled or something. So that's how I've set up all of my repos. For me this has taken off a huge burden.
I don't agree with locking threads after they've closed though. There is very little reason to do so.
One way that I found out recently in the vite github repository [0], is to use github actions cron job to automatically close issues with certain labels, like "needs reproduction".
This way maintainers need to at least explicitly set the label before the issue is closed automatically, and not the other way around.
That's right. It's all use-case based. Indiscriminately closing issues automatically is definitely wrong. Automatically closing issues that cannot be reproduced or have other issues is a perfect use-case for stale bot.
Using GitHub's stale bot you can set it to ignore labelled issues, and so it's up to maintainer to label things correctly. Once the maintainer does so, stale bot won't touch it.
I believe that's backwards — it requires active effort from the maintainer (who may be on vacation) to prevent closing, when the ball is in the maintainer's court (to check if it's a reasonable ticket). The process described elsewhere in this subthread, where the maintainer has put a label on the issue before it can be auto-closed, is better (since the next action is on the reporter); that must only happen if the reporter hadn't responded, though.
I think the problem is that the bot is the wrong solution to the problem.
It's like when I was clearing out my inbox of spam - about 10% of the garbage was legitimate spam, the rest was self-inflicted spam - ads for places I frequent, and mailing lists that I kept thinking I would read 'some day'.
What I needed was a way to group all of the suspicious messages so that I could machine gun my way through them spending less than a couple of seconds each. First hour got a lot of dead messages quickly, slowing down over time and totaling about 4k messages by hour four (most of that spent in front of a TV, which let me finish but also made it take longer - if you ignore the divide by zero error).
What you need is a way to tag suspicious issues so that you can go through and veto the 20 that are legit, and delete the rest. But that may require some feature requests to GitHub, and a different bot.
I can get behind closing stale issues, to a certain degree, but this practice sound straight-out stupid: Why would you discard the context of a previews discussion?
At the risk of spinning of a tangent flamewar: this ties into a wider issue that boggles my mind to this day - the concept of "necroposting" as something negative. People will commonly want to eat you alive if you post a new reply under a stale discussion thread, but that reaction feels really dumb. The old context is useful.
If the old context is useful, sure. but it often isn't, and that's what causes people to dislike necroposting. But without a specific policy/instance in mind discussing this is a bit moot, since everyone has a different level of reasonableness in mind.
There's at least one forum out there where necroposting is actually valued by the culture. It's considered cool and fun to make a relevant post on a thread that was last updated five years ago. I love that.
For me the reason I see it mostly as something negative is because most necroposts are pointless. They're often only written because the author forgot to check the date and thus didn't realise their comment won't contribute anything useful. Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists.
> the author forgot to check the date and thus didn't realise their comment won't contribute anything useful
I have a different view of those in most cases - particularly on large, or publicly accessible, boards. That comment may not contribute anything useful for the people previously involved, but it may very well be useful for everyone else - such as any person that finds the thread through a search engine.
> Like when a user tells others in a 7 years old, obsolete thread they're wrong because shiny new solution XYZ exists.
That's a specific case about one-upping someone much later, but a more generalized case - posting modern solution under unresolved problem thread - is very valuable for people who find the thread looking for a solution. Conversely, blanket ban on "necroposting" discourages accumulation of knowledge on tough problems.
I agree that a blanket ban on necro-posting has the negative consequences you mention. It is commonly discouraged as a heuristic, because necro-posts often have a high time cost to those who were previously involved. First, because by that time they've forgotten the context, and since the new post often does not summarize the entire previous conversation, it forces someone who wants to make sense of it to go back and re-read it to understand that context. In contrast, a new issue is more likely to stand on its own and be easier to process. It can still link to the old issue in order to keep the chain intact. And second, because the new commenter is often wrong that their bug is the same, or has missed some of the context and is just adding duplicate information. Note that both of these apply more to long threads.
I think this suggests two things:
1. There is an opportunity for better tooling. I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url). Imagine that but with any bug that's been marked as a duplicate (which the bug reporter should be able to do). Now you get the best of both worlds -- a way to view the new post with or without context.
2. Necro-ing would be less problematic if bug tracking were less centralized. More long, support-type bugs between distributors and users, where is preferable to log a new issue than necro an old one; more short summaries of confirmed bugs submitted by maintainers to the upstream repo. GitLab's separation of issues and epics is a good idea here, although their implementation is awkward at best.
> And second, because the new commenter is often wrong that their bug is the same, or has missed some of the context and is just adding duplicate information. Note that both of these apply more to long threads.
That's a good point I haven't considered. Yeah, the consequence of mistakenly starting a new topic under an unrelated old thread is that the new discussion is now miscategorized and harder to find.
> It can still link to the old issue in order to keep the chain intact.
Yes, that would be great. If one could pull off an UI that nudged people to correctly link back to older threads, so that such links were typical, I think it would mostly solve the necropost problem - the etiquette could be changed to "don't necropost; if starting a new thread on a topic that was discussed in the past, ensure your post links back to those old discussions".
(I think I saw a few boards automatically generating a box with "related topics", but IIRC, their method of finding related topics yielded lots of false positives. If improved, this could work too, though I would still prefer explicit links that don't change over time.)
> I'm thinking something like those annoying infinite scroll news/blog sites, where you reach the end of the article and it dynamically sticks another one on the page below (& updates the url).
I personally don't want that. I hate this UI pattern. In particular:
- As implemented on social media platforms, it makes it nearly impossible to find your way back to something you saw a minute ago but scrolled past.
- As implemented on news sites, auto-appended articles are usually not relevant to the one you just finished.
- The URL substitution is particularly annoying - usually, the time I care about the URL is when I read/skim the article to the end, and then decide to share or bookmark it. At that point, the URL will already be changed to point to a different article, and it's easy to miss. And the way these feeds are implemented, if you follow the link to a follow-up article and scroll up, you won't get back the article you actually wanted.
The blanket rule is because even "good" necroposts tend to encourage bad ones. If I'm on an active forum and I revive some ancient discussion with a useful comment, lots of people will click on the thread and try to argue with the old posts.
The generally recommended alternative is to make a new thread and simply link to the old one so you don't confuse people.
> boggles my mind to this day - the concept of "necroposting" as something negative.
I never understood it either. I mean, as a religion.
What is even sillier, is that as far as web forums are concerned, you have 50% of them which will go mad if you "necropost", and the other 50% which will go mad if you open a new thread when there is already an existing thread on the same topic (even buried), because these have the exact opposite written or unwritten rule. The latter ones love their 800 pages long topics; the former ones forbid you to follow up with a discussion even when it is the exact same topic, if the discussion stopped for a while.
You know what beats that still? I've been using a few boards where people believed in both these things at the same time. So when a topic stalled, it was nigh-impossible to resume it later.
I've seen something a bit like that: moderators who would come down hard on people who ask a question, both in an old thread or a new one (because the first time they were told not to create new threads or not to necropost so they tried again, following the advice, in the opposite manner), by telling them "why can't you search the fucking forum 2 minutes before digging an old thread / creating a new thread, stupid; this has been answered multiple times: here, here and here; topic locked", and of course none of the links he gives does answer the specific problem the posters had and clearly specified, because the mod didn't spend the said 2 minutes reading the posters' questions and just stupidly copied the first search results in the rush he had to punish the intruders. So, when you hit the same problems as the posters, you are out of luck, because their questions were not answered before, and they will never be.
I have seen this unfortunate behaviour in mailing lists for some Open Source software as well. Gatekeepers with anger issues and too much time on their hand (but not enough to actually answer the question). Sometimes I wish these people realised how hostile they are and unwelcoming to new users and potential contributors, but maybe that’s the point.
The result is ~10 relevant hits when you Google an error message with not a single useful solution.
Agree for intelligent discourse about a slow-moving topic. Disagree for conversations about personal opinions (most of forums), especially ones with time context. When you post on a three year old thread, everyone else has left the room. That's fine if you want to share how you finally got this old sound card working on a specific OS, lame if there was a lively discussion about working at Lyft versus Uber.
Firstly there's a 3rd type: someone asks for help and you post a suggested solution 3 years later. Extremely useful for all the lurkers who also had the same question and are reading looking for possible solutions.
But secondly, even your own counterexample I don't think checks out. If I'm browsing your forum & interested in perspectives on working at Lyft v Uber, I absolutely want to read a recent update and contrast that with what people thought 3 yrs ago v now.
Tbh, the "I got my sound card working" post seems least appropriate of them all (but still ok to do imo, necroposts are good)
My sound card example was supposed to be like your 3rd type, so we agree there.
Old and current experiences are definitely both valuable. Just start a new thread. It's too easy for other members to miss the dates when it comes back to the top. Then they're reading and responding to old posts from absent people like they're here and now.
I don’t think “necroposting” is something inherently bad[0], but specifically insisting (or expecting) that open-source project maintainer remembers a 100-screen thread every time anyone wants to bring it up is IMO ill-mannered.
A random person online invests an afternoon to read through a years old issue thread and decides to comment, expecting the maintainer to reply. Meanwhile, maintainer has dozens of such issues, and dozens of frustrated users bringing up each of them every week. Asking the submitter to respect a previously made maintainer’s decision, file a new issue and invest their own time to concisely summarize the status quo seems only fair.
In other words, diverting discussion to a new thread is a chance to compress old context into a short summary, like you would squash a Git history—except in this case the old closed issue thread is fully linkable and isn’t going anywhere.
[0] That said, it depends on maintainer’s personality. I can see how some could feel losing control and demoralised by ever-evolving difficult-to-track discussions on previously closed issues.
You're right that this behaviour is bad and I know that what you describe happens but it seems like a strawman argument in the context of this discussion.
What you describe is about the community respecting foss maintainers; closing tickets is not going to solve this problem.
I was responding to the point about comments piling on a closed issue. It is not bad by default, but still there can be valid reasons for maintainers to discourage it.
Whether an issue should be closed or should be allowed to be re-opened by the public is not even up to debate as far as I’m concerned, this is up to maintainer’s policy.
+1E100. On a busy project it's disasterous if long-lived chronic bugs which are serious enough to be tracked in the first place, but have never quite made it to the top of the todo list, randomly got closed for no good reason. This issue is a classic case in point. We have too many similar ones on Matrix (but which we've been slowly working through over the years).
When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate and with little in the way of automatic triage determining the priority it is a borderline impossible task to wade through them.
Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.
> When you can only tackle so many things there is 0 point in having a bug tracker that will only inflate
A public bug tracker isn't just for you. It, arguably, isn't even primarily for you. It's for all your users who experience a problem and want to confirm if someone else also had it, and if there's a known solution.
(It's something that particularly annoys me as a developer. I can fix problems on my own just fine, thank you. But I want to know if my problem is something tied to my configuration, or a known issue of some software that's failing for me - so that I don't waste time looking for the cause in the wrong place. I want the project's issue tracker to help me answer that question quickly - and auto-hiding/archiving/closing stale issues makes this job much harder.)
> A public bug tracker isn't just for you. It, arguably, isn't even primarily for you.
There is a lot of work still to be done on bug-tracking. The eternal attempt to keep users away from bugtrackers has meant that, when they inevitably became public because of FOSS growth, their interfaces did not really work for users.
I think it's high time we accepted bug trackers are also forums. There should be a way to mark certain comments as "effective workaround", and surface them at first glance. There should be ways for developers to mark certain comments as "useful info" so that the rest can be filtered. There should be ways to have lengthy discussions attached to the bug but not forced on the developer. There should be incentives to actually solve "historical" bugs first. In short, there should be different ways to look at a bug depending on one's role, without losing anything, without alienating anyone, and accepting the complexity of user-developer relations.
That's a great perspective. I agree with what you wrote here.
With that in mind, I believe that properly supporting all the various use cases an issue tracker serves without turning it into another JIRA is a hard UI design task.
But at the same time, practices like closing or locking stale bug reports can be seen as UI workarounds. Some people feel their boards are cluttered, so they reach for the only tools available - the close button, the lock button, an autoclosing/autolocking bot. It solves the UI issue for them, at the expense of other groups of board users.
This is to say: it's ultimately an UI deficiency on the part of a common issue trackers. Developers should be able to restructure their board as they see fit, but it shouldn't impact other users' ability to utilize the data stored on it. It would be great if major software forges solved this on their end.
Perhaps we need a concept of a "stale" issue/thread that's distinct from a "closed" one. A stale issue would be one that's not actively being looked at, but is nevertheless not resolved. The way it would differ from a regular open issue is:
- It doesn't sort itself up when somebody posts a comment on it.
- Posting on it doesn't notify people who didn't explicitly subscribe to it - all activity on stale issue is grouped under a single, inconspicuous indicator, that can be easily ignored.
- Stale issues are always sorted to the bottom or kept on a separate tab, and are trivial to filter in or out during searches. But the tab marker itself stays visible, so that people can find out there are such issues in the first place.
- Stale issue can be explicitly promoted to active at the discretion of the developers (or perhaps by community vote).
Hopefully this would reduce the need to aggressively close - and especially to lock - older issues.
PHP's documentation allowed (allows? Not sure anymore) comments. Especially in the pre-StackOverflow days, this was absolutely brilliant. I'm sure that's a pretty heavy moderation burden for any successful language (especially these days, maybe not as much when PHP's docs first added that feature) but damn it's nice.
I love the idea of bugtracker-as-forum (you're right that they already are and we're just in denial about it and don't design them to do that well) but it's the kind of thing that doesn't seem productizable (how many companies would want that, for instance? I doubt many) and non-commercial non-trivial open source isn't such a lively field, lately.
As an example of this, the SQLite bug tracker [0] is closed for submissions from non-developers (or some set of trusted people), and instead the SQLite forum [1][2] is used to discuss possible bugs.
Because - per the pattern of behavior we're discussing in this thread - some developers close old issues, whether they were actually resolved or not, and it's becoming a common practice, particularly with the appearance of bots performing this function automatically.
Also, not everyone is using the most recent release.
Some issues are not actually bugs but user errors (e.g. because they haven't read the manual). Personally I'm not sure if it's better to close such issues or keep them open with a special label.
I do, because I realized people close stale issues just because (and then there are bots that do it now too). I'm happy I can still do it, and I worry that one day someone will have a bright idea to "archive" closed issues to where they cannot be easily found.
Stalebot (the popular one on GH) has exemptions which are configurable - branch, author, label, commenter, and probably more. AKA owner/maintainer can do as little as drop a label or even just a reply on an issue and it won't be pruned.
No, it's a method of automatically discarding valuable information.
To put a different spin on what TeMPOraL said: a bug is roughly defined as a deviation from expected program behaviour. It is not defined as a deviation from expected behaviour which we intend to fix soon. There is value in keeping track of all the bugs in a codebase, even the ones you don't intend to fix soon.
That is to say, a bug tracker is for tracking bugs. It is not a to-do list. (edit Although I wouldn't want items on my to-do list to expire without my knowledge, either.)
If you want to mark a reported bug as Not a bug or Won't fix, that should be done manually. If a bug was fixed in passing as a result of some other work, the bug should be manually marked as fixed. It doesn't make sense to have a timeout act as a stand-in for a triage decision, in a way that fails to distinguish between these two outcomes.
> No, it's a method of automatically discarding valuable information.
So.. a filter.
I didn't claim it is a perfect filter. I did claim it is _a_ filter and one may subjectively decide it is a better choice than trying to track an ocean of issues which, if you're someone the size of Mozilla, will be a vast majority of "It crashed" useless issues anyway.
_If_ something is that important, it will come up again and closed issues can be referenced. Again, no claim that this is perfect from me.
> Allowing duplicates is fine, the important stuff comes up again whilst the unimportant bits die off.
You lose a lot of context from other reporters, and some discussion that could happen between reporters. All of this allows diagnosing an issue, and sometimes solving it without input from the team ("ah, this 3 years old bug? I solved it, turns out I had faulty memory, check yours").
I dislike closing them, especially as github only has two states: open and closed, and doesn't distinguish with invalid, wontfix, fixed, stale, needinfo, etc.
At least they are still searchable and interactable with when closed, but who thought it was a god idea to lock them? All the original subscribers won't be notified of new discussion on the topic.
That's a straw man. It's a balance between your time and theirs, and I presume you don't think that all bug reports are carefully considered and well-written. Many are even obtuse, aggressive and self-entitled. I'd bet most well-written, civil bug reports are at least taken seriously, even if they end up as a wontfix.
There's nearly zero cost to leaving a stale bug report open. A few kB, and maybe not even that because closed tickets are rarely actually deleted.
If you're not working on a bug, then, by definition, it's not taking up your time.
Some people are just obsessive about not wanting to look like they have open bugs on their project. But closing tickets and fixing bugs are not the same thing.
> There's nearly zero cost to leaving a stale bug report open.
Triaging an endless list is very costly.
I do agree with the idea that if you expect your project to be public (and not just something you did that you'll share if somebody wants) it is a cost you are expected to take. But it's wrong to pretend it's free.
Triage is what happens when you first look at a new ticket and decide what to do with it, any encounter/interaction after that is not a triage.
If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling: tickets should only be closed if they're malformed, solved, or (arguably) wontfix.
I've always interpreted "triage" as the first response whenever something comes up (paralleling the medical term were it's from), is that not how it is?
> I’ve said it before and will keep on saying it: GitHub’s stale bot should be removed with prejudice.
Imagine if the Linux kernel or even Chromium had stale bots closing reported vulnerabilities everywhere. It's like they are burying bugs waiting to be exploited by drive-by security researchers.
Android, notoriously, does this. When (not if) you hit an Android bug while developing an app, more than likely you'll find it closed as stale. Luckily they don't usually block comments, so you'll get to see confirmation from within the last few weeks that you're not crazy and this bug is still present, and maybe some up-to-date workarounds if you're lucky.
Amen. About once a year I spend an entire day reopening bugs in the Qt bug tracker while somewhere in Finland someone is sitting there closing them, like a sort of really annoying game. The process consists of (a) downloading the minimal test app attached to the bug, (b) making a trivial change to get it building with the latest Qt, and (c) reopening the bug with the remark "this still happens in Qt X.latest". Unfortunately I can't quite do this as fast as they can close them...
In an ideal world I'd agree with you, but if you or your team don't have the time to fix every bug - some of which will not be critical - then having a mass of open issues pile up often leads to people being overwhelmed and fixing even fewer. Also, over time, some issues are superceded by changes elsewhere so they become moot anyway.
I agree that auto-closing bugs is unfortunate, but I understand the motivation.
I've worked on legacy codebases with thousands of unresolved issues old enough to drink. Those issues were probably triaged and reproduced by the people who hired the people who hired me and had been lovingly transferred during multiple bug tracker migrations, but they never achieved high enough priority to warrant development attention. And certainly no one on the current team had any interest (or time) to dig up and attempt to reproduce issues that no human has touched in a decade. Just reading through all the old issues would require a larger team than the product revenue could sustain, let alone reproducing and resolving them.
Having said that, there was no harm in keeping old issues "open" because everyone on the team used metadata to filter old issues out of their views so they were effectively "closed" in that no one ever saw them unless they deliberately went looking and they stopped being included in summary reports. No idea whether people would consider that better or worse than explicitly marking them as "Closed".
Not sure if relevant to open source bug tracking, but I've worked in more than one company whose "old bug" policy boiled down to: If after we found this bug, we chose to ship an update that did not include a fix, then the bug is not important enough to ever fix and should be closed as "Won't Fix". In other words, customers have lived with this bug for at least two release cycles and the world didn't come to an end, so don't prioritize it. I don't agree with this policy but I think it's a pretty common mentality in the commercial software world.
EDIT: Additionally, I've never worked anywhere where the capacity/willingness to fix bugs exceeded the incoming rate. So net bug count minus fixes would always grow forever unless you regularly purged unfixed bugs. This seems almost universally true in software.
That's a good point in general, though the product example I gave was primarily funded by government contracts and (at least based on the negotiations) the contracts were far more sensitive to price than quality.
But I will say that my experience in enterprise software has been similar. The relationship between software quality and company success is more a bell curve than a linear one: if you neglect quality you'll certainly lose customers, but above a certain point if you spend too much of your budget fixing every bug you'll eventually lose to competitors with mediocre quality but lower prices and/or more capabilities.
In general I don't disagree, but I'd moderate the position with context.
For projects that have some sort of product manager who is personally in charge of managing and perhaps de-duplicating the tickets, I'd leave the choice up to them. Some like having only one ticket that captures all discussion about an issue. Some don't care, and aren't so worried about losing track of comments from several years ago. That feels to me like a work style issue, and I don't need to tell them how to do their job.
Or, for projects that are working with an issue tracking system that makes it really difficult to juggle large numbers of open tickets, I also see it as potentially valuable. It's a trade-off. Yes, you get a little extra chaos from broken discussion around perennial issues. But, if you simply cannot effectively manage and prioritize more than, say, a hundred open tickets, then that might be the lesser of two evils.
An issue where the reporter is unreachable and developers do not have local reproduction should absolutely be closed as it serves no function other than generating noise in the issue tracker.
Open issues is a liability to overview and planning, and having bad open issues is therefore directly harmful to maintainers, reporters and users.
Closing a bad but ultimately real issue will just make way for a possibly good report to take it's place (i.e. a new reporter rather an old unresponsive one) so it only provides benefit.
not searching closed issues is always bad, things that are fixed in a newer version or after long discussion are closed as won't fix won't be found either
This is even worse, competitive projects are compared to each other based on number of OPEN issues, making the project that ignores "stale bugs" look better than project that keeps bug until actually solved. I've seen this thinking twice in action, a teach leads decided to use react native over flutter, because RN had fewer issues
As a bug reporter I take it very personally when it happens to me.
When I try to debug a problem and I see it has already been reported and closed due to inactivity (that is :not fixed. Not tagged won't fix) I give up, I won't fight the machine.
I disagree for bugs in volunteer open source because it requires someone to triage it and recreate the bug cross versions. Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid
The process of closing it means pushes that work back on the users obviously this requires the coders to keep an eye on the bugs and assess their importance
Having 8000 bugs cross 10 years with ancient versions helps no one
> The common practice now is to "close stale issues", which was discussed recently, though I can't find the thread.
This is bad and borderline dishonest practice, and it’s surprising that it’s allowed to be widespread. I wrote an edgy post about it which didn’t go far on HN but it’s a sentiment I don’t see repeated much (without the edge of course).
Filed issues say something about your product or it’s documentation/UX. Bots that autoclose muddy that signal.
Au contraire, I think they amplify that signal! It sends a pretty clear message to people who file these annoying issues as well as acts as a deterrent to would-be pests who search for an existing issue before filing.
I dunno, if you want to do that it would actually be better to just send that clear message in a more direct manner -- GitHub just doesn't have good tools around this yet. Until better tooling gets here, maybe it makes sense to just very quickly ban pests, and make it clear that pests won't be tolerated?
Also I want to point out that I'm totally fine with quickly closing tickets with no reproduction details or without enough information. Bad tickets should get closed if they're bad, especially if there's a template in place that the person has ignored. I would say that if 10 tickets from different people are getting filed from a specific area it may be worth looking at even if all the tickets are badly specified. In general a closed ticket with an explanation is so much more valuable over time than the alternative.
I think CGamesPlay was being sarcastic. I interpret “would-be pests who search for an existing issue before filing” as describing good-faith bug-filers from the apparent perspective of repo maintainers who auto-close stale issues.
> if you want to do that it would actually be better to just send that clear message in a more direct manner -- GitHub just doesn't have good tools around this yet.
Doesn't it have the ultimate tool: If you want to send the message that you don't give a shit about bug reports, just don't activate any bug-tracking tool? (Or is it mandatory?)
No, it doesn't. If you want send that message clearly, you should state in your readme: "We don't give a fuck about bug reports, especially if they're valid and relevant.".
Yes, it says that the product is popular enough that hundreds of people feel the need to post feature requests with notes like “how is this not fixed yet, it should be five minutes of work, it's a deal-breaker issue for me, I'm migrating to Chrome if this is not fixed!!!”
It just creates an incentive to game the system. Stale issues get closed after 90 days? Run a script that asks for an update on the issue every 89 days...
Wow finally! I have to admit while I love Firefox using it on macOS just feels crappy as it is so out of place. I am a huge user of the macOS "Look Up" content menu feature and it being missing in Firefox always frustrates me.
As silly as it sounds this might just be enough to get me to use Firefox as my main browser on macOS. I have played around with Nightly recently and love the new UI design. Can't wait for this to hit release.
Indeed I just tried out Nightly and am disappointed it is missing. I have given them a little nudge so hopefully they add Look Up to the context menu before this hits stable.
I know this doesn't get you 100% of the way there, but pressing Cmd+Ctrl+D while hovering over a word brings up the "Lookup" window in Firefox 88 (similar to Safari).
I just tested this in Firefox and it works on the highlight which is inconsistent with how it works elsewhere. Usually it selects the word under the cursor not the selection. Perhaps Firefox is doing something to change the default behaviour?
I actually experienced the opposite on my M1. Safari locks up all. the. time. but it happens more often when I open a new tab. I run into a ton of compatibility issues, and I hate that you can only install plugins via the App Store.
I really wanted to like safari since it’s the most power efficient, and when I got my M1 I went all-in on it, but I went back to Firefox after three months.
Blake Ross[0] was 15 years old at the time of that comment. It was two years before he, Dave Hyatt, and Joe Hewitt published the first version of Firefox.
Ah, "native" and "firefox" really makes me miss Camino, which was a pretty great mix between OS X standard UI features and the FF rendering engine. But apparently keeping that up to speed with Firefox main releases was way too much effort (probably one of the reasons why there are plenty of webkit/chrome shells and almost no Firefox ones).
The big reason was that Mozilla ended embedding Gecko with Firefox 4/Mozilla 2. This made it nearly impossible to run Gecko in anything but an XUL shell. I understand the reasons cited at the time, largely available resources, but it was very short-sighted and I think it hurt Gecko's mind shares in the long run.
I loved Camino as well. A truly excellent browser.
Gecko ending embedding is almost certainly a major reason why everything built with a browser engine is either a Chromium wrapper (not true embedding, but no browser chrome) and WebKit (true embedded).
It’s a real shame. Gecko is a nice engine but XUL is a much harder sell.
Correct. It's not intended as a Gecko replacement, and several important components in Servo are already part of Gecko. Servo will continue to evolve and new features will originate from it, but it lacks a lot of the legacy and quirks rendering (intentionally) that would be required to make it a full-fledged engine of its own even if Mozilla wanted it to be.
Wow, that issue is older than OS X itself, which I assume it means it originally referred to Classic Mac OS. It's nice to see it tackled after all this time, AFAIK Mozilla doesn't even support XUL anymore.
Judging by the massive number of dependency issues (bugs, etc) that appeared in the bug history once they started working on moving to native menus, I guess it really was a time-consuming thing to fix :)
If the menu was already implemented in a generic (non-native) way for other OSes, then making a specific native implementation for one OS is more work and thus more time.
One thing that bugs me is that on macOS access keys[0] are not underlined. This means I can't pick an action with the keyboard and have to use the trackpad. Anyone know how I can enable it / if that's even possible?
As a recent Mac user, I don't know if this is a mac thing, but I hate not being able to use the keyboard to navigate around the UI. Although the trackpad is nice, it can't beat the precision of the keyboard. I can't focus the menu bar, trigger a context menu with the keyboard, tab around panels and buttons. It's an accessibility nightmare.
I find using macOS with a keyboard near impossible.
One of the issues is how hard it is to discover what the right keybindings are.
Second issue is that all the keymappings are different to Windows/Linux/BSD/AnythingElse.
Like, in the setup wizard when you open a new mac, hitting "return" won't move you to the next step, you have to hit tab, and then space. However, near the end of the setup process, there's a screen where tab doesn't work, and you actually DO have to use return.
I'd had carpal tunnel (and it's kind of a chronic thing), so using a touchpad to point-and-click is literally painful for me. A mouse is okay, but it seems to be impossible to connect bluetooth devices on macOS without using the touchpad.
> One of the issues is how hard it is to discover what the right keybindings are.
In addition the display in the menus, you can use the keyboard settings' shortcuts section to see the global keybindings and add new ones either globally or within a particular app.
> Second issue is that all the keymappings are different to Windows/Linux/BSD/AnythingElse.
There's a bit of early GUI history which explains most of this – MacOS was the earliest mainstream GUI and they had guidelines pretty early on which most Mac applications use. A decade or so later IBM decided they needed to create their own standard (Common User Access) which they pushed to get implemented on OS/2, Windows, and other operating systems.
Mac users continued to want what they were familiar with, and applications which were business-focused in the late 80s-90s got CUA, and a whole lot of other software got some agglomeration of whatever the developers were familiar with and/or the toolkit they were using provided by default.
> I'd had carpal tunnel (and it's kind of a chronic thing), so using a touchpad to point-and-click is literally painful for me. A mouse is okay, but it seems to be impossible to connect bluetooth devices on macOS without using the touchpad.
Two ways:
1. If it's an Apple mouse with a lightning port, plug it in once with the cable.
2. It sounds like you might not have activated the accessibility setting which toggles tab navigation from only navigating between text fields to all controls. Use Control-F7 to toggle that and then:
1. Open settings – you can use Spotlight via Command-Space or Option + either the sound or display adjustment keys to open Settings without using a pointing device
2. Either navigate the icons or use search to select Bluetooth
3. Hit tab, the default focus ring will be on the “Turn Bluetooth Off” button if full control navigation mode is enabled.
4. Hit tab, focus will now be on the devices list
5. If your mouse is pairable, it'll show up with a connect button. Use the arrow keys to select that line and hit enter.
Interesting bit of history, I was unaware of the details here.
A page with a list of shortcuts is terrible for discovery though. I can't open a browser all the time to try and fine if something is there (not to mention apps not listed there).
I think the solution used by others of always including it in menus and tool-tips is a lot better for discoverability.
My biggest gripe continues to be consistency though. Apps may use Cmd, Ctrl or Alt for shortcuts, with no clear pattern.
This has the added problem that it's super hard to create global shortcuts that don't overlap with any app. For example, on Linux, no apps use Cmd (Super), so you're free to bind Super+Anything for your own global shortcuts, and you'll never shadow any app. If I try using Super+w (or Ctrl+w), I'll quickly come across some app where I'm shadowing a shortcut.
This is very confusing to me: the shortcut keys are listed in the menu bar for every application. Is that somehow disabled on your system? (I'm not even sure that's possible off-hand — it's been the default going back to the 80s)
Similarly, consistency is the opposite of what I see. Every app I use uses the standard Command shortcuts. Control/Option/Shift are modifiers in some cases (e.g. Command-V pastes, Shift-Option-Command V pastes preserving style, etc.) but the only time I've seen other keys in use has been a few stragglers with deeply-engrained conventions like Emacs.
The most perplexing one that stands out in recent memory is in the file explorer, where pressing Enter doesn't open the selected item, but begins a rename operation.
I might be misremembering but isn't there a key combo ([Fn] + [Ctrl] + [F7] or something?) that enabled control selection and shows the underlines. I haven't used Mac OS for a while so I might be wrong!
On Windows I find it hard to remember random letters for accessing menu items. On macOS when a menu is active I can start typing the name of an item to go to it, which is easier for me because I remember names better than random letters. For frequent commands I learn the keystrokes.
There is no Mac equivalent to this Windows feature.
You can set up a shortcut to move keyboard focus to the menu bar in Keyboard preferences under Shortcuts (in fact you can remap any application’s keyboard shortcuts there). That’s also where you can enable keyboard navigation between controls.
That focuses the menu bar for keyboard navigation. The question was about the fast navigation keys Windows has on menu items, which has no Mac equivalent.
One thing that bugs me is that on Windows access keys[0] are underlined. This means I accidentally hit the ALt key all the time and some unintended action happens. Anyone know how I can disable it / if that's even possible?
As a recent Windows user, I don't know if this is a Windows thing, but I hate inconsistent keyboard navigation in the various UIs. Although the keyboard is nice, it can't beat the precision of the mouse. The unwanted focus on menu bars, the unwanted triggering of menus with the keyboard, and too many modes: tabs and panels and dialog boxes. It's an accessibility nightmare.
Not exactly what you asked for but a pretty great tip is to use Command-Shift-/ to select the search field in the Help menu, and using it as an ad-hoc command palette for all MacOS apps.
You're a lifesaver, thank you! That was exactly what I've been looking for.
I've played around with `ui.key.menuAccessKey` before, but I needed to turn off native menu (`widget.macos.native-context-menus`) to display the access keys.
I'm not sure if this is what you're looking for, but the first thing I enable on a new install is tabbing between UI elements and pressing enter to use them.
If you go into System Preferences -> Keyboard -> Shortcuts (tab)
There will be a checkbox at the bottom that says 'use keyboard navigation to move focus between controls'.
Leaves me feeling a little contemplative... will the stuff I'm logging in my project's issue tracker still exist in 2040? Will my project be relevant, or even remembered? Is the company we're working for even going to be around?
I think the time to get rich off JavaScript is now - I hear webshops still pay ludicrous salaries, but junior web developers are being manufactured in great quantity, so the market will eventually saturate.
Another way of looking at this is: it's a great life extension hack!
One of the problems with cryonics is, how to motivate future people to revive you in the first place? Learning (and having it documented) a technology on which global economy is going to be critically dependent for decades to come sounds like it should do the trick.
(Another problem is, how to motivate earlier future people to keep you around until your value becomes apparent, which will likely happen only when your services are direly needed on short notice.)
And I'm not saying this because I think it's the best ever, or because I don't learn from history and how things change.
It's the nature of the web. We're still dragging things from HTTP/0.9 and and from HTML 1.0 along.
But also, JS is a capable script engine with millions of USD put into engineering VMs into it, and the networks effects are inescapable. I don't see WASM replacing it either. They'll be used in tandem.
At my previous workplace some of the copyright headers said 1991.
However, it had been through the source control of Theseus; CVS -> SourceSafe -> SVN. When I left there was talk of moving to git, but since the build system checked in binaries that was a serious obstacle. The bug tracking similarly had been through at least one reset.
I still regularly see code here that's 10-15 years old and some code that's older than the company itself. It's both surprising and a bit scary to see how much code is still flying around that hasn't (or has barely) been touched in so long. Or even the idea that code can transcend companies and end up in entirely different places.
Just downloaded the beta. I was hoping this meant that right clicking on selected text in Firefox on macOS would let me look up the word in the macOS system dictionary (e.g., in both Safari and Chrome, if you right click on a selected word, the first result in the context menu is `Look up "<word>"`).
It's such a convenient way to learn new words (and even works across multiple languages). Alas. Maybe in a future update!
(Another, similar, gripe is that both Safari and Chrome, along with most other native macOS apps, will select the word under the cursor with just a right click—no need to even double click to select first and then right click. Firefox doesn't do that.)
You can force click a word to trigger dictionary lookup. But I'm not sure how to get it working with a selection rather than only the word under the cursor.
1. Select the word and hit ^⌘D or ⌥⌘D. The former opens the definition in a pop-up, the latter opens it in the dictionary app.
2. There is an extension that adds a context menu item that opens a new tab on the Oxford definition of the selected word at lexico.com [1]. The same extension author also has one for the Cambridge dictionary.
You can just use the search option in the right-click menu. Google will give you the definition of the word for most words you actually want the definition for.
Not having the "Look up ..." available from the context menu is my biggest pet-peeve with Firefox on MacOS.
I know you can force-click on laptops, but, not everyone is on a laptop all the time, and force-clicking doesn't allow you to choose the selection, which can be quite problematic for languages that doesn't use spaces.
Looking "native" on Windows is a very difficult thing these days. To me classic Win32 is what "looks" native whereas all their modern apps like Mail and Calendar don't look native at all even though they are.
Office is native but has its own, unique look and feel that is different to other native tab interfaces built into Windows.
And don't get me started on context menus in Windows (ironic given this story). The design and items on a context menu is so inconsistent it drives me mad at times.
Consistency in Windows is a real pain point imho. I would love for Microsoft to just stop adding more crap to the shell like some weather or contacts fly-out and just spend a year getting everything consistent with a good, modern light and dark theme that works everywhere. I know it is easy for me to say that though.
(Office is not native. Easy to check since all the controls behave in their own particular ways, even on dialogs, and the look is strikingly different from the rest of the system controls. Most exacerbated if you run Office 9x on NT 3.x).
There are a bunch of considerations for the native look-and-feel that go beyond the primary visual aesthetic. Using the OS-specific terms, shortcuts, font-sizes, button order, APIs. This maintenance effort is not trivial. This is all stuff people at Mozilla are trying to look out for.
But additionally adopting the design language of the system is another burden altogether. It potentially triples your design- and implementation time and adds a lot of complexity to your code. And if you're unlucky the next OS version requires you to change it all again.
Proton will kill the native LnF on all platforms in Firefox in a Badum! way. The context menu on Windows isn't native either btw, in that it doesn't follow the OS theme. Ironically, on Linux, the context menu has always been properly styled according to the active GTK+ theme...
That's always been the case. After Win95 came out, every OS revision and Office release changed the default look and feel. It was most noticeable in the toolbars. Started out with visually raised buttons (like regular interface buttons), then the buttons went flat, then the whole toolbar was raised via a gradient, then everything went bonkers with ribbons (meanwhile in browsers you had huge buttons with text below as yet another alternative).
Or the checkmark/cross ok/cancel buttons that were quite common (Borland?).
That "old" look and feel co-existing with "modern" flat/web designs just made the differences more noticeable, never mind the often associated differences in icon sizes and styles.
Not that other systems are better. Linux always had too many widget toolkits (and now those awful upside-down window-title-toolbars), and even Macs always had at least one weird option (e.g. brushed metal or too iOS-like thingamajigs).
Ah but you see, all the core details remained the same since Windows 95. Some from even earlier. Flat buttons, raised buttons, buttons with round corners, they all had the same dimensions, margins, padding. Same goes for all the other details like menus. Indeed, this remains the same even today, in the Run dialog, Win32 applications like Notepad, …
Some things changed, like window chrome and the shell (taskbar, start menu). Ribbons came. But the core design language remained unchanged. Until Modern UI.
The Firefox context menu is of course not “native”. However, in Firefox 88, it has the look I would expect. The way it looks in basically all Win32 applications. In Firefox 89, context menus are inflated, comically large.
Just because Microsoft is butchering UI consistency doesn’t mean other software has to follow suit.
And this is frankly ironic because for so many years one of the biggest complaints against desktop Linux by Windows user was the lack of uniformity between Qt, GTK and other toolkits interfaces.
Probably some wish to be consistent for all firefoxes across all platforms. It's pretty common for x-platform software, and I think a big mistake. Most people don't move across platforms that often and those that do already encounter so many other differences a print dialog being recognizable won't make much change.
A person is a "Windows user", and prints on lots of applications on Windows, and expects a consistent experience across all applications.
Same applies for Linux users and Mac users.
A person is not a "Firefox user", who prints of Firefox on Windows/Linux/Mac. The few people who _do_ fit this unique profile, are very much used to seeing very different dialogs on all three platforms.
Also, printing in 2021? I get that people still print, but it seems equivalent to improving the Fax dialog in 2006.
> Also, printing in 2021? I get that people still print, but it seems equivalent to improving the Fax dialog in 2006.
Free coloring pages (like: outlines of characters or whatever, you can easily find these with image searches) for your kids.
Worksheets for homeschooling or school supplementation, or if you're a teacher.
DMing RPGs if you want more than one screen of stuff visible at a time, or are trying to avoid screens at the table. I find, especially, printing relevant monsters or character sheets for likely combat encounters in a session to be super useful—saves you flipping back and forth between a bunch of things on a screen or doing the work of condensing stats, you can underline and notate one or two spells on the sheet so you're not searching at the table for "what would this magic-wielding creature probably cast first in combat with this party?", for a repeat-encounter big nemesis that the party comes to hate you can let the party rip up the sheet when they finally dispense with them, that sort of thing.
Most of the RPG stuff also applies to serious study or working-with-references. Screens still aren't a replacement for 20 sheets of print-out paper that I can have spread out on my desk all at once, and fold, write on, stick in a desk drawer for later, cram in my pocket, flip over to sketch something on the back, whatever.
Tale as old as time! I remember getting into almost a shouting match with a UI designer over this common conflict. Is it more important that the app's UI is consistent with other apps on the user's computer, or is it more important that it is consistent with the same app across all platforms (and consistent with the company's self-defined "branding")? I argued that the user expects all his apps to be consistent and look like they fit in with their other apps on the system, and the designer argued that the user doesn't care, and that our company's designers knew better than Microsoft/Apple/etc. about the best User Experience for our particular app. Seems like reasonable people can disagree about this.
This is also a great example of why you need good user testing: a designer is hyper aware of what they’re trying to do design-wise, developers tend to focus on implementation and support, and we’re all too familiar with the product to represent users well. I’ve seen plenty of things like that where everyone spends months on it and the outside users don’t notice/care or point out that, say, the custom design didn’t work with their system font settings or screen reader.
This. GIMP's save/open file dialog on Windows is, for the lack of a better word, graphics and usability-wise disgusting. Confusing and fiddly controls, no thumbnails (on a graphics application!) If anything, they should replace the GTK open/save dialog with something that mimics the Windows one.
They want to show a full-sized print preview, which isn't possible on Linux or Windows (I don't know about OS X)
A preview is important as web designers seldom pay much attention to print stylesheets; the user probably doesn't want to print five pages of navigation menus, or print a black background with white text.
Yeah, given the number of people who run Firefox on Windows, you absolutely need to have a custom print dialog for them. Maybe it should default to the system one on OS X, but you gotta have that custom one.
It has nothing to do with engineering resources, and we always wanted native context menus, but they were not customizable enough to meet the perceived needs of web, XUL, and extension developers at the time. People expected to be able to change colors and layout with CSS, for example. The native APIs put heavy limitations on what you could do with a native context menu and it was just not compatible with the expectations of people building against the rendering engine at the time.
There was some discussion of switching back and forth between native and non-native menus based on styling, but that got complicated quickly and it wasn't thought to be worthwhile.
It sounds like perceived needs have changed, and maybe the native APIs allow for bit more flexibility now. Glad it's happening, excited to see how well it works!