Use native context menus on Mac OS | Hacker News Reader

Use native context menus on Mac OS

bugzilla.mozilla.org

587 pointsreid294 comments

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.

> Computers don't excite me

Honestly kind of a depressing thing to read on "Hacker News", not that I disagree that UI consistency is good

I observed myself leaning in same direction.

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.

Looks like Macromedia Flash and KidPix had a baby. It's a bit of a nerve calling it "Power Tools", to be honest.

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]:

https://www.youtube.com/watch?v=xt06OSIQ0PE&ab_channel=LGR

>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:

http://www.vintageapplemac.com/files/misc/MacWorld_UK_Feb_20...

>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.

The Interface of Kai Krause’s Software:

https://mprove.de/script/99/kai/index.html

>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]

METAMEMORIES:

https://systemfolder.wordpress.com/2009/03/01/metamemories/

>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.

Macintosh Garden: KPT Bryce 1.0.1:

https://macintoshgarden.org/apps/bryce-1

>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.

MACFormat, Issue 23, April 1995, p. 28-29:

https://macintoshgarden.org/sites/macintoshgarden.org/files/...

>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.

I'm sure that's a big part of it.

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.

That's exactly the wall I ran up against with ActiveX pie menus.

https://news.ycombinator.com/item?id=27276093

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.

The common practice now is to "close stale issues", which was discussed recently, though I can't find the thread.

It's nice to see the inverse of that, I doubt anyone would have replied every 90 days for 21 years.

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.

> And they are all so simple that there will never be a problem.

"Simple JS can't have unexpected security/performance pitfalls".

Hah.

https://www.cvedetails.com/vulnerability-list.php?vendor_id=...

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]

[0]: https://portswigger.net/daily-swig/prototype-pollution-the-d...

[1]: https://github.com/Kirill89/prototype-pollution-explained

[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3]: https://shieldfy.io/security-wiki/prototype-pollution/introd...

What's the security risk?

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.

Also known as the "Cascade of Attention Deficit Teenagers" (CADT) development model:

https://archive.is/l4svG (jwz link, so archive.is)

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...

How is underscore these days?

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.

> "ripping" for me is associated with "ripping media" which is copying video/music/data from CDs to local hardware

For many others, the OP's use is common and correct—in a lot of areas.

"They ripped me off" is very prevalent in English speaking countries too, outside of tech.

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.

Really, lodash was a fork of underscore, not a reimplementation. The git history shows it.

https://github.com/lodash/lodash/commits/0.1.0?after=e0971cd...

Perfect, even better! Now we can all correct ourselves and call it a fork, which sounds much nicer than "rip", "ripoff" or "clone".

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

More accurate is 'stolen code without proper attribution'

https://raw.githubusercontent.com/lodash/lodash/4.17.10-npm/...

> Based on Underscore.js, copyright Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors <http://underscorejs.org/>

They've given precisely as much attribution as is required.

Hope you don't publish any MIT code and then blame people when they fork it. That'd be really against the spirit of the MIT license.

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.

Here are the versions I looked at:

- https://web.archive.org/web/20120826202523/http://lodash.com...

- https://web.archive.org/web/20130502014523/http://lodash.com...

- https://web.archive.org/web/20140517192947/http://lodash.com...

- https://web.archive.org/web/20150513014815/https://lodash.co...

- https://web.archive.org/web/20160803063412/https://lodash.co...

- https://web.archive.org/web/20170830163720/https://lodash.co...

- https://web.archive.org/web/20180703043557/https://lodash.co...

- https://web.archive.org/web/20190803030353/https://lodash.co...

- https://web.archive.org/web/20200615092636/http://lodash.com...

- https://web.archive.org/web/20210314233141/https://lodash.co...

Good digging. The 2012 banner is

    > A drop-in replacement\* for Underscore.js

I'd consider this to be an admission of where the API came from.

You are right though, my memory failed me. No mention of forking.. Shameless!

"Rip-Off Menu" is another term of art for "Tear-Off Menu". ;)

Inside Macintosh > Macintosh Human Interface Guidelines > Part 2 - The Interface Elements > Chapter 4 - Menus > Tear-Off Menus and Palettes

http://mirror.informatimago.com/next/developer.apple.com/doc...

>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.

Rip short for rip off which can mean a clone essentially.

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.

You haven’t addressed the hostile attitude of the maintainer, which was the point.

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.

It's not as if "Person or group B are also objectively arseholes!" logically invalidates "Person or group A are objectively arseholes", is it?

I disagree. It entirely depends on the behaviour.

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.

[0]: https://github.com/vitejs/vite/blob/b6d12f71c1dbd5562f25bc2c...

This is different from closing legitimate bugs/issues that are well described and testable, just not fixed.

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.

Show me a bot that can tell the difference between a testable and well described bug and one that's affecting lots of users but has bad descriptions.

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.

How is that different from someone closing the issue manually?

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.

Worse is when they prevent you from reopening or if you comment after it’s closed you get a rude response to open a new ticket.

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.

Which forum?

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.

See also: https://xkcd.com/979/

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.

but that's just a reasonable response to a specific type of comment, not a general defense of banning necroposts outright.

The reason the term exists is because it's a blanket rule based on the age of the reply, not based on the intent or context.

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.

Ah! :)

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.

Getting redirected to post on a locked thread where that's not allowed... I propose to call this the Catch-302.

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).

Meh. It's just a method of filtration.

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.

But there is very little money in it, I guess.

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.

[0] https://www.sqlite.org/src/reportlist [1] https://www.sqlite.org/src/wiki?name=Bug+Reports [2] https://www.sqlite.org/forum/forum

> There should be a way to mark certain comments as "effective workaround", and surface them at first glance.

Is there a reaction emoji that signals "effective workaround"?

We need a "duct tape" reaction emoji.

Come to think of it, we need a "duct tape" emoji. I'm surprised it isn't in Unicode already.

There's this one in the extended block: https://www.fileformat.info/info/unicode/char/1fa79/index.ht...

Closing an issue shouldn't prevent anyone from finding it though. At least on GitHub closed issues are still visible in the issue tracker.

I think closed issues shouldn't be a problem on the current release. So why search through them?

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.

Who search for closed issues when searching if other have the same bug?

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.

I do. Because perhaps it's fixed in a newer version or ...

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.

> Meh. It's just a method of filtration.

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.

No, not "a filter". A filter is like "SELECT .... FROM TABLE WHERE ...."

This is "DELETE .... FROM TABLE WHERE ...."

> 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.

AFAIK when a closed/locked issue is referenced, watchers get notified. If they don't I agree they should.

It’s fine, as long as the time he submitter spent to write a decent bug report is worthless to you.

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.

You don’t need to wait for a certain period of time to decide that a bug report is poorly written.

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.

> If maintainers feel like they need to close tickets only to keep order, than that's a problem with the tooling

Oh, yes. Yes it is!

I think you were downvoted because the first part of your answer is wrong, but this one hits right on the mark.

Priority is a constantly moving slide.

> But closing tickets and fixing bugs are not the same thing.

You can't measure how many bugs you have, but you can measure how many bug reports you have. ;D

If you can automatically close old bugs then you can automatically filter those same bugs, without closing them.

> 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.

Why not move them to a low visibility category like a back-burner?

Some long standing problems get progressively easier to fix when the blockers around a bigger problem gets conquered slowly due to requirements.

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.

> Just reading through all the old issues would require a larger team than the product revenue could sustain,

Yeah, well, if it weren't so full of decades-old still-unsolved bugs, then maybe the product would have more users and therefore more revenue?

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.

It's all about finding the right balance.

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.

It depends solely on the definition of "stale".

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

FWIW In this case it’s a feature request

> Vlc version x.y.z on Ubuntu version a.b.c cross versions of vlc and Ubuntu is it still valid

This sentence missing lot grammar.

So much so that I really can't even see which direction of the argument it's arguing for or against.

This came up in the javascript-world.

It helps people gain a sense of productivity when a lot of yak shaving place.

> 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.

Agree with sibling that GP was sarcastic.

> 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?)

> It sends a pretty clear message

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.".

> Filed issues say something about your product

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!!!”

Ban those people then -- no one is entitled to have their voice heard in the comments of your issues, or even to file issues on your project.

Also, this comment wasn't about Firefox specifically! Just about projects that do this in general.

Compare browser market shares when this bug was posted and now, they did leave.

A common practice is to also LOCK stale issues, disallowing any further discussion.

IMHO, it's a terrible practice, since it pushes for infinite duplicates completely losing the trail of previous discussion.

> The common practice now is to "close stale issues", which was discussed recently, though I can't find the thread.

Maybe this? https://news.ycombinator.com/item?id=26590961

Previous discussion on pretty much the same topic: https://news.ycombinator.com/item?id=26256459

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.

Look Up still isn't in the context menu - https://bugzilla.mozilla.org/show_bug.cgi?id=1116391

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).

Does this still has the bug where Lookup can only look up a single word even when multiple words are selected/highlighted?

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?

The trackpad/mouse gestures for Look Up (eg. force pressing the trackpad) work in Firefox.

It's very sluggish on a Mac. Even on my shiny new M1 is feels sluggish. Safari is way snappier.

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.

I had taken the habit to use cmd-ctrl-d while hovering over words (in any app really)

This is a fun comment:

>Blake Ross

>Comment 5 • 21 years ago

>How easy/hard would this be?

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.

[0] https://en.wikipedia.org/wiki/Blake_Ross

He even wrote his own fanfic episode of Silicon Valley!

https://techcrunch.com/2015/09/04/the-founder-of-firefox-wro...

I think he is at Uber now, not sure if that is still the case.

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.

Servo is the theoretical successor in this regard, like so many other regards, right?

Is the goal of Servo to replace Gecko eventually? I thought it was more of a testbed for new rendering techniques.

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.

> OS: Mac System 8.5 → MacOS X

Indeed, it was first described against MacOS 8.5… that's a memory trip!

That's funny that it was reported against Mac OS and fixed in macOS, skipping OS X entirely.

macOS is just a new marketing term for OS X (albeit a different revision). Whereas classic Mac OS is fundamentally a different OS.

Opened midway through the PowerPC era. Lingered for the entirety of the Intel era. Finally fixed at the dawn of the ARM era.

"Hey, why not use native context menus?"

"I can't argue, but it's a time thing."

21 years later...

"Fixed."

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.

[0]: https://docs.microsoft.com/en-us/windows/win32/uxguide/image...

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.

There's also a pretty comprehensive version here:

https://support.apple.com/en-us/HT201236

> 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.

Remember, on a Mac it's not an Enter key, it's a Return key. It's not used to enter a file.

On Windows, you use Ctrl-O to open a file from within an open program.

On a Mac, you use Cmd-O to open everything from everywhere; it's a universal (within Apple) convention applied consistently.

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!

Edit: I'm impressed I even remembered that! https://support.apple.com/en-gb/HT204434#fullkeyboard

I always flip that setting on Macs. The default just seems wrong to me.

Whilst that is the keyboard shortcut for that setting, it doesn't appear to underline access keys.

Ahh, I thought it did both, but that must be misremembering. A quick search indeed confirms there doesn't appear to be a way to do it... Apologies!

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.

Its control F2

https://support.apple.com/en-us/HT204434

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.

[0]: https://developer.apple.com/design/human-interface-guideline...

I honestly don't know if you are joking or not. MacOS is superior to Windows in many ways but this is clearly not one..

⌘? is a good way to get to the menu bar on macOS.

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.

1. Disable native context menu (macOS native menus will never support access keys)[1]

2. Go to `about:config` and set `ui.key.menuAccessKey` to a custom value (I have it at 17)[2]

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1711299

[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1711299#c5

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'.

This will do what it says! Hope this helps.

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?

There are still issues that come up at my work that nobody wants to tackle because that part of the company is running off fortran.

I predict JavaScript will be the Fortran of 2040

If I can get the legendary FORTRAN sacks of gold, I’ll happily take Promise.then.then.then.then in 2040

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.

As all markets, juniors are everywhere and easy to hire but what companies really want are good developers, and those will always be hard to find.

All the good COBOL developers had themselves frozen.

https://donhopkins.medium.com/cobol-forever-1a49f7d28a39

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.)

JavaScript isn't going anywhere, I believe.

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.

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.)

Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1116391

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.

This has been fixed recently and force clicking will look up the selection rather than try to do a Smart Selection.

I don’t know if it’s an macOS fix or Firefox fix, but it works like you’d expect now.

You can tap the word with three fingers to look it up in the dictionary (you might have to enable it in trackpad settings)

A couple workarounds.

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.

[1] https://addons.mozilla.org/en-US/firefox/addon/oxford-englis...

If you use a Force Touch capable trackpad, force touching a word opens the dictionary.

I'm amazed anyone finds that useful. I've had to disable it due to constantly accidentally activating it.

I almost never accidentally force click. You can increase the force required before it activates in settings.

Alternative recommendation I have is to setup launcher/terminal script for word definitions - retyping the word aids with memorization!

For MacOs I use Alfred launcher and just click option+space "define myword"

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.

You could file a bug for that! The macOS team at Mozilla is trying to make changes to be a better mac citizen (see native-context menus) :)

Already open - https://bugzilla.mozilla.org/show_bug.cgi?id=1116391

Looking forward to 2042!

Using Firefox now, making a selection and then force-clicking it opens it in Look Up

You are right. That must be pretty new. Thank you for letting me know - this is really useful for me!

This was available in my late 2017 macbook pro with force touch. I know because I don't like this feature and was searching for a way to disable it.

Didn’t work on Japanese text for me just a few months ago. 2018 MacBook Pro.

Meanwhile, on Windows, there’s nothing left of the browser that looks native.

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).

It's easy to complain about Apple changing the macOS look every year, but boy, Windows hasn't had a single 'look' since the Windows XP era...

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...

On Windows, no app looks "native". There seems to be no standard native Windows look left after years of idiotic redesigns and missteps by Microsoft.

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.

I doubt that windows users would care, mac users maybe. Number one complaint is lack of pro software like photoshop or ms office.

Windows used to be more consistent. Now the Windows users who cared gave up Windows or gave up caring.

Then again, most MS applications have never looked "native" on Windows either -- it seems each team has always gone for their own style and UX.

If you right-click in default Microsoft apps that ship with Windows, you can expect one of like 5 types of menu to appear

Now if only they’d use the macOS native print dialog like every other app. What ever possessed them to roll their own print dialog?

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.

I agree completely on how stupid this is.

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.

The macOS print dialog has a number of pdf options I use frequently.

In the coronavirus age, reading printed materials causes me less eyestrain than reading on a computer screen.

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.

GTK(3+?) can actually easily use the platform open/save dialog with GtkFileChooserNative.

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.

Thank you, that explanation makes sense.

IMO you should get a preview (with options for changing the rendering), and you can go from that to the system dialog. Instead of combining them.

I don't know why the trend, but Chrome also uses its own print dialog by default.

I kinda like Chrome's more than the alternative though.

Chrome's good on Windows, but on macos it's a mess, at least on my machines. No preview generation, weird scaling issues, ...

Some product designer in MTV needed something to do

Probably because the Windows system dialog is horrible ;)

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.

Turn off print.tab_modal.enabled in about:config.

A 21 year old bug. At that point the developer creating the fix could have been younger than the open issue itself

And the bug can legally drink alcohol (in the silly still-over-21 US).

This bug is old enough to run for president:

https://www.youtube.com/watch?v=u729hGPyi6M&ab_channel=Silve...

Every now and again I get an email about a bug I commented on sixteen years ago that was opened 21 years ago: https://bugzilla.mozilla.org/show_bug.cgi?id=57342

It's kind of nice to see that they will, eventually, get round to issues like this.

Comment in December 2000:

> Yes, WONTFIX and INVALID seem a bit much. We'll just keep it in the database for eons.

That joke aged exceptionally well!

And it breaks my workflow..

When I read a webpage, I often select some words (technical terms, movie names, etc), right-click, and press "S" in the keyboard for quickly googling the words. I tried it in Firefox Developer Edition (equivalent to Firefox Beta) which already has native context menus, and it didn't work.

Can't believe this happens to me: https://xkcd.com/1172/

I am in the same boat. There is an about:config flag to revert the behavior and use old menus. I am not sure whether the new mac-native context menus even have a notion of access keys, so I am not hopeful for a fix.

Impressive! I like how this makes the browser's UI simpler and more predictable.

Also, this is especially useful for people using dark mode, since native context menus match that setting.

One of the problems I've found with native context/drop down menus is that when you're sharing a specific window on Zoom, the context menus don't show up on the video.

You have to share your entire screen to show someone all the available options in the context/drop-down menu.

That's because context menus are a separate top-level window with their own event loop on all windowing systems (even macOS, I think). The drop-down you get on a combo-box is a similar deal, at least on Windows and X11.

But but.... There is no data. There is only XUL

The cynic in me thinks this just happened because of a code rewrite they wanted to do anyway for reasons unrelated to this bug report. It’s just a coincidence that the rewrite allowed them to close it. (The initial report mentioned XUL, which if I understand correctly, isn’t even used in Firefox any more.) This is hardly some kind of a commendable instance of listening to your users.

I mean, compare it to this bug report:

https://bugzilla.mozilla.org/show_bug.cgi?id=309807

First the response was ‘just use an extension’. I did that happily, until the extension API was neutered, making the extension non-functional. When people brought that up, Mozilla closed comments on the bug report. Now it is closed as WONTFIX with this laughable excuse:

> Extension APIs (which I know aren't yet available) would be the solution for implementing this if there is enough demand.

Meanwhile, Chromium had this from day one. It works a bit differently now, but it’s still there, I just checked. Doable? Perfectly doable.

Better late than never

Related: Can anyone share the google search to find instructions how to get started with firefox development?

Have they removed it all? I can find old stuff in the archived github repo, but that's about it. What's the official entry point?

for developers: https://firefox-source-docs.mozilla.org/

all categories: https://www.mozilla.org/en-US/contribute/

unsure how you can help? https://whatcanidoformozilla.org

Thank you, it's a shame the first link doesn't show up on google.

I've found the contribute page, but that leads straight to https://github.com/mdn/archived-content/tree/main/files/en-u...

I’d love to have the “Look up” option on the menu. Every time I right click I am again reminded of its absence. So, hopefully “soon”.

I just hope there's no regression. :)

Hope it wasn't P1 for the full 21 years.

Edit: Bumped from P3 -> P1 3 months ago :)

Some things are not meant to be fixed hehe. I love old bugs!

That is a very long bug, 21 years in the making lol

About that color management thing...

https://bugzilla.mozilla.org/show_bug.cgi?id=455077

I have always wanted to implement pie menus as a Firefox or Chrome extension, but I've never been able to find a sufficient API that enables me to pop up a modal dialog window at any place on the screen (specifically: centered on the current mouse cursor position, and in an operating system window that exists outside of the browser tab, overlapping all other windows). Or reshape it to any shape (or simply respect the alpha channel of the document and not show any chrome), so I can make a round or arbitrarily shaped window shrink wrapped to the items.

https://developer.chrome.com/docs/extensions/reference/windo...

Is there a way with that (or any other) API to pop up and precisely measure and position an arbitrarily shaped (alpha channeled) window, without any other chrome or window frames? And then globally capture and track mouse and keyboard events?

Does anyone know if there's now a way for a browser extension to do that in any browser? Or would it require hacking platform specific C++ operating system code?

Here's a demo of an ancient implementation of pie menus I made for ActiveX around 1997, that shows pie menus with arbitrarily shaped windows:

ActiveX Pie Menus: Demo of the free ActiveX Pie Menu Control, developed and demonstrated by Don Hopkins.

https://www.youtube.com/watch?v=nnC8x9x3Xag

ActiveX Pie Menus doc, examples, sources, etc:

https://www.donhopkins.com/home/catalog/piemenus/ActiveXPieM...

https://www.donhopkins.com/home/catalog/piemenus/PieMenuDesc...

I did all the drawing with Win32 calls, so you could configure the fonts and colors and sizes and window shapes and styles, but you couldn't style everything arbitrarily with css, embed arbitrary web content, or anything nice like that.

At the end of the demo video, I concluded that:

>I ran up into a wall of complexity with this ActiveX control, in that I wanted to be able to have as the menu items animated gifs, mpeg movies, fonts with nice attributes, and things like that.

>So the first thought was "well let's just put a whole web browser in every item!"

>But that was a little heavy-handed. So instead, I put the pie menus into the web browser as a Dynamic HTML Component. Which I'll show next.

Of course it makes a lot more sense to draw and style the pie menus with the browser's renderer, but I still want the best of both worlds, where I can pop browser-drawn pie menus in arbitrarily shaped and positioned operating system windows, and track the mouse globally (capturing the mouse and keyboard events and receiving mouse motion and up and key events outside the window, to pop up and track sub-menus properly).

JavaScript Pie Menus: Pie menus for JavaScript on Internet Explorer version 5, configured in XML, rendered with dynamic HTML, by Don Hopkins:

https://www.youtube.com/watch?v=R5k4gJK-aWw&ab_channel=DonHo...

You'd probably want to use ‘native messaging’ from the extension for this: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

I think it's sufficient to override the ‘contextmenu’ event and signal to your app where to show the menu and what to show in it. You can even implement the menu itself in something like Hammerspoon on Mac, with Lua APIs—dunno about Linux. However you'll have to define the whole menu yourself, since you don't have info on the browser's one.

Though it might possibly be easier and more performant to have websocket communication with the app—it means the app will have to stay open, but that's not much of a problem in this case. OTOH I'm not sure that browsers won't start blocking requests to localhost servers, after the privacy issues.

That's in interesting approach. But my desire is to implement the rendering of the pie menus in the same browser that is popping up the pie menus.

If it has to run in a separate app, then that app must embed its own separate browser than the one popping up the pie menus.

Since it's a lot easier on the Mac to embed a Safari browser than a Chrome browser, it might be amusing to have Safari handling the pop-up pie menus of Chrome, but it wouldn't be the optimal solution of Chrome (or Safari or Firefox) drawing its own pie menus.

Chrome's browser window extension api almost but not quite works for my purposes, and I wonder if or why it was a design decision not to make it more flexible. Security? Browser extensions, like clowns, can already get away with murder.

> implement the rendering of the pie menus in the same browser that is popping up the pie menus

Eh, I'm pretty sure it's quite a bit easier and faster to draw a radial menu with proper drawing primitives, like in Hammerspoon's API. Gotta admit I have no idea why you'd want animated pics or videos in such a menu. Though Hammerspoon's docs say that the drawing API does ‘support’ GIFs in some way, dunno exactly how.

As a bonus, you could then invoke those menus in apps other than the browser, though you'd need some access to the UI, like AppleScript or accessibility APIs—which are typically neglected in cross-platform UIs.

How many developers and designers know how to draw using Hammerspoon APIs? Now how many know how to draw using web browser APIs? And how many people are actively maintaining and evolving Hammerspoon APIs, versus how many people are actively maintaining and evolving web browser APIs?

It was quite clear to me in 1997 that I did not want to play catch-up to the web browser by programming an ActiveX OLE Control pie menu using the Win32 API and GDI to draw as nicely and as flexibly as web browsers could draw using HTML, CSS, VML/SVG/Canvas, etc. It's easier and faster to not reimplement (and maintain) the wheel.

And who are you or I to say that the people designing pie menus don't want to use animated gifs, mpeg videos, Canvas, WegGL, or provide rich application specific real time visual feedback and animation during tracking, or do anything else in their menus that html is capable of?

If you can't come up with a use case for menus with animated gifs, it's just a failure of imagination, not proof that menus with animated gifs are a bad idea. A web app should be able to easily use its very own web content in the exact same format to illustrate its menu items.

In fact, I actually wanted to use animated gifs as pie menu items myself, and the demo video I linked to of my first Dynamic HTML implementation of pie menus shows animated gifs and html tables in the "Punkemon" pie menus, for example (at 3:00).

https://www.youtube.com/watch?v=R5k4gJK-aWw&ab_channel=DonHo...

(Sorry the graphics design and layout are atrocious, but I implemented that two decades ago, and the whole point was to piggyback on the next 20 of web development, not try to reimplement it all by hand.)

Notice how (at 6:50) I use an XSL spreadsheet to transform the XML database of Punkemon characters into a set of illustrated pie menus rendered with html, tables, and animated gifs.

In 2001, the web browser already has an XSL stylesheet processing engine built in, which you can use for dynamically rendering richly formatted pie menus from XML data, and it fully supports animated gifs, tables, and all html and css features out of the box. Does Hammerspoon?

That's exactly what I mean about being able easily to use your native web content and technologies in menus.

JavaScript pie menus (implemented circa 2001 for Internet Explorer with Dynamic HTML Behavior Components):

https://donhopkins.com/home/PieMenu/piemenu.htc

https://donhopkins.com/home/PieMenu/punkemon.xml

https://donhopkins.com/home/PieMenu/punkemon.xsl

https://donhopkins.com/home/PieMenu/JavaScriptPieMenus.html

>Pie Menus are specified in XML.

>Standard, simple syntax for describing arbitrarily nested trees of pie menus. The syntax of XML pie menus is very obvious and easy to read, learn, modify and create.

>Pie Menus are configured with reasonable defaults, so the XML menu descriptions are concise. And designers can easily override the defaults, and customize the properties, behavior and visual appearance of any pie menu, item or submenu.

>XML Pie Menus can be automatically generated and used by many XML tools and applications, including XSL style sheets, web servers, databases and XML editors.

>The Punkemon Pie Menus example shows how to use an XSL style sheet (punkemon.xsl) to automatically transform an XML database (view source of punkemon.xml) into a web page with nested pie menus (Punkemon Pie Menus).

>Pie menus are easy to configure and customize in many ways.

>Pie menus have default attributes that can be easily overridden and specified for a whole menu or any individual item.

>Pie Menus are rendered using Dynamic HTML.

>Arbitrary Dynamic HTML can be embeded in XML Pie Menu specifications, to define the appearance of the pie menu center and items. Anything you can describe in DHTML can be used to make pie menus.

>Pie menus support arbitrarily shaped images in the pie menu center and items, as well as dynamic control over the background appearance, highlighting and transparency effects.

>Pie menu callbacks can dynamically alter the content and appearance of the pie menu center, items and web page in response to user input. The Style Pie Menus demo shows how the pie menu callbacks can dynamically modify the properties of the text on the web page, to provide immediate and intuitive feedback.

>Pie menus can be easily integrated with ActiveX, DirectAnimation, JPEG, animated GIF, PNG, MPEG, QuickTime, Flash, Java, and many other technologies supported by Internet Explorer. The Direct Animation demo shows how you can easily integrate pie menus and interactive structured graphics created with Direct Animation.

>The Punkemon Pie Menus demo shows how pie menus can incorporate animated GIF images and dynamic HTML effects like scaling, as well as large pie menu items containing HTML tables and formatted text. [...]

>Dynamic HTML is a flexible, well known, widely supported and graphically expressive markup language, used by pie menus to define their visual appearance and interactive behavior. Pie menus support the XML-based XHTML standard, which is the new XML compliant version of Dynamic HTML, because it cleanly nests inside of XML pie menu specifications, and is easily generated by XSL style sheets and other XML processing software.

>The pie menu component supports a full set of callback events, so JavaScript of VBScript code on the web page can dynamically track pie menu browsing and selection, to implement selection handlers and rich interactive application specific feedback.

I always thought that the "marking menu" style in Maya was always a neat implementation. Keeping the traditional context menu to not alienate regular users, but offering radial and gesture style navigation was really a great choice for its niche.

A power-user software that makes heavy use of mouse manipulation is perfect for those kind of "enhancements" of traditional ui elements.

The marking menu style made the learning was more pleasant than let's say the very keyboard shortcut heavy interface of Blender. But I feel like after struggling a while with the shortcuts, using Blender felt faster after the learning curve.

So maybe there's some niche between expert systems and beginner friendly apps or in embedded devices where such "intermediate UI" solutions are better at home.

It seems this is the ‘marking menu’: https://lesterbanks.com/lxb_metal/wp-content/uploads/2014/02...

But it looks pretty dubious from the perspective of Fitts' law. The items to the left and right are vaguely okay-ish: they're long in the direction of cursor movement, however you need to hit the narrow vertical profile while there's empty space above and below each item. The top and bottom items, though, are narrow in the direction of cursor movement while being far enough from the mouse that the movement will have some speed. It's the same problem as Windows' menus have, only closer to the mouse so not that pronounced.

Meanwhile, in a classical radial menu, the items are closer to the cursor and they should have considerable depth in the dimension of cursor movement if they use icons of non-microscopic size.

you don't actually need to hit the boxes, you just need to point into the direction.

So, right click, drag, release. That's enough to trigger one of the options. Over- or undershooting are not an issue.

You also don't need to wait for sub-menus to appear, so if you know there's a menu going north, south, north. Then you can just drag your mouse up, down, up in one motion and it will detect the direction changes.

> you just need to point into the direction

Ah, indeed that's better if I understand it right—depending on the actual target areas.

I remember using something like this in Firefox a long time ago. A search suggests it was Optimoz/RadialContext: http://www.mozillazine.org/talkback.html?article=2407

There's at least a current attempt at the same idea, posting to test it later: https://addons.mozilla.org/en-US/firefox/addon/easygestures-...

when will be the turn for https://bugzilla.mozilla.org/show_bug.cgi?id=734643 ? 9 years already.

I wish I could donate just to fix this bug for everybody.

But I don’t use them any more only brave

Reply on news.ycombinator.com