Hacker News Reader

Comment by Ukv | Hacker News Reader

My guess, having never used OSX:

1. In the save dialog, filetype can determined in multiple ways (maybe selected from a dropdown, or be set by the program opening the dialog) and not necessarily just inferred from user-entered filename

2. So when returning the path to the program, it appends the filetype's extension to the path iff it doesn't already end in it (so user can enter just `notes` and file gets saved as `notes.txt`, if that was selected in the dropdown or the program's default)

3. Probably unintentionally, they've started allowing partial matches when inferring filetype from the user-entered filename

e.g: User enters `database.sql`, it matches against `.s` extension of assembly filetype, but `database.sql` doesn't end in `.s` so becomes `database.sql.s`

View on HN

It's just a bug.

The system save panel (NSSavePanel) is only supposed to infer the file extension when it has been given a list of supported file types/extensions. If the user does not specify a file extension, NSSavePanel will use the first extension in the supported list. If the user specifies an unsupported extension, they see an error message.

Text editors like VSCode and Sublime Text would configure NSSavePanel to allow any file type/extension, which means it's supposed to just accept whatever the user types.

> It's just a bug.

It's an unforgivable bug.

File save dialogs have been around for decades. There's no reason whatsoever to not have very extensive unit and integration tests around it.

Exactly, and when you interview for companies like this you have to basically prove that you are in the top 1% developers in the world, just to find shit like this being released in the wild for millions of devices. It is absurd.

Better never navigate through AOSP source code.

Sure there is, 3 reasons:

1) No one writes unit tests for old code until it breaks the first time, because they're too busy working on new stuff.

2) No one gets assigned to write unit tests for old code until it breaks the first time, because there's always more work to do than you have time to do it in and if its not broken, its not hurting anyone enough to get resources and time diverted to it

3) Even if you write a mess of unit tests for stuff, it's always possible to miss unit testing a specific scenario. 100% line and branch coverage is not 100% bad outcomes or 100% possible inputs.

I've never worked anywhere that had 100% of their code tested with automated tests around 100% of the possible inputs and outputs. And the older the code and the longer it had been running stably, the less likely it was to have that testing if the testing wasn't written with the code. Like everything else in development, tests add up in the technical debt pile too.

Good guess! This has always seemed like a tricky edge-case-ridden feature, so I’m not super surprised it eventually broke. I mean, this is the kind of thing that should be covered by automated tests, but who knows what’s going on internally…

Personally, I’m putting good money on someone “fixing” some regex constant while doing another bug by either disabling full-match or taking off the “useless” $ at the end. This is why you don’t do unrelated fixes!! Otherwise, I don’t see any way this would get past ticket review as an intentional change in any half-awake dev team.

I iTunes had a very similar "autocomplete tries to be helpful but causes chaos" bug a few years back. If you clicked to edit the artist column it would autocomplete from the list of other artists in your library. However, if your desired artist name was shorter than one it's trying to autocomplete, it would forcibly append the rest of the name from the longer artist.

e.g. if you typed "Ross" and wanted it to just be "Ross", but you have any track by "Ross from Friends" in your library, it would always append " from Friends" no matter how many times you tried deleting it.

I remember this, how annoying! I think you'd work around it by pasting.

That explanation actually makes some amount of sense. So if the application doesn't supply a file type, the dialog Ingers the file type from the filename. So when the user has typed "database.s", the dialog sets the file type to assembly, and it keeps that setting even as the user goes to add "ql".

Reply on news.ycombinator.com