Use native context menus on Mac OS (opens in new tab)

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

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.

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.

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

For projects that have some sort of product manager who is personally in charge of managing and perhaps de-duplicating the tickets, I'd leave the choice up to them. Some like having only one ticket that captures all discussion about an issue. Some don't care, and aren't so worried about losing track of comments from several years ago. That feels to me like a work style issue, and I don't need to tell them how to do their job.

Or, for projects that are working with an issue tracking system that makes it really difficult to juggle large numbers of open tickets, I also see it as potentially valuable. It's a trade-off. Yes, you get a little extra chaos from broken discussion around perennial issues. But, if you simply cannot effectively manage and prioritize more than, say, a hundred open tickets, then that might be the lesser of two evils.

An issue where the reporter is unreachable and developers do not have local reproduction should absolutely be closed as it serves no function other than generating noise in the issue tracker.

Open issues is a liability to overview and planning, and having bad open issues is therefore directly harmful to maintainers, reporters and users.

Closing a bad but ultimately real issue will just make way for a possibly good report to take it's place (i.e. a new reporter rather an old unresponsive one) so it only provides benefit.

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.

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

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

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.

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

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.

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.

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.

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

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

The old-style extensions were so powerful because they could put their API tentacles very deep into the rendering engine. Mozilla paid a huge price for allowing that though - it was very difficult to change the behavior of many parts of the rendering engine without breaking extensions. Much of what you'd think was just internal implementation detail was actually API surface accessible to those extensions. The workarounds added a bunch of internal complexity. It really slowed down the pace of development.

I get that some people mourn the loss of that style of extension, but dropping it was an important decision that should have happened much earlier. There were other issues with the old-style extensions (e.g. security) but making the pace of development uncompetitive should have been enough to doom it.

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

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.

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.

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.

It’s a real shame. Gecko is a nice engine but XUL is a much harder sell.

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

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