Skip to content
This repository has been archived by the owner on Sep 6, 2021. It is now read-only.

User-created file associations (via Open With) are wrong after updating #4882

Closed
peterflynn opened this issue Aug 22, 2013 · 9 comments
Closed
Assignees

Comments

@peterflynn
Copy link
Member

Windows
This can't be tested yet because there is no "Sprint 31" build, but:

  1. Install Brackets Sprint 30
  2. Right-click a JS file > Open With > Choose default program
  3. Select Brackets
  4. Install Brackets Sprint 31
  5. Double-click a JS file
  6. Uninstall the old Brackets Sprint 30
  7. Double-click a JS file

Result:
5 - launches old build (Sprint 30)
7 - pops up Open With dialog (no file association set anymore)

Mac
A similar bug might exist on Mac, but my testing there was inconclusive. Launch Services has some sort of heuristic for choosing which .app to launch when multiple apps have the same id. On my machine, setting a file association from an installed .app always causes it to actually launch my dev build instead. So we'd need a clean machine to test on in order to see how this will really work for users.

@peterflynn
Copy link
Member Author

For Windows, @bchintx and I have an idea that might fix this:

  • Make all versions of Brackets lay down the same ProgID in the registry
  • Whenever a newer version of Brackets is installed, it rewrites the ProgID to point to its .exe path
  • Since file associations "redirect" through the ProgID, this means the newest version of Brackets will always be launched
  • Uninstalling old builds requires some tricky logic though. The uninstaller should only remove the ProgID from the registry if the build we're uninstalling matches the current .exe path. That would allow uninstalling old builds safely and would still clean up the registry once all builds are uninstalled (it would mean that rolling back to an older version by uninstalling the newer version loses your file associations though -- probably an ok edge case to leave un-fixed).

For Mac, I'm not sure what the fix would be or if we need one.

@peterflynn
Copy link
Member Author

Btw -- for Edge Code, the situation is slightly different:

  • Win -- Upgrades occur in-place, so all we'd need to do to fix is is keep the same ProgID across releases. The .exe path doesn't change. (This is assuming we don't run a "full uninstall" of the old version when upgrading, which is a current Edge Code bug).
  • Mac -- Upgrades also occur in-place, so this might already work.

@ghost ghost assigned ingorichter and ryanstewart Aug 26, 2013
@pthiess
Copy link
Contributor

pthiess commented Aug 26, 2013

@ryanstewart to discuss with @adrocknaphobia

@njx
Copy link
Contributor

njx commented Sep 19, 2013

This seems important but possibly backlog-level work?

@njx
Copy link
Contributor

njx commented Sep 19, 2013

Nominating for sprint 32

@njx
Copy link
Contributor

njx commented Sep 19, 2013

@gruehle also pointed out that this would be obviated by in-place upgrades in Brackets. I added a card for this to the icebox: https://trello.com/c/xxabXFIG - it might be worth doing that work in lieu of this.

@bchintx
Copy link
Contributor

bchintx commented Sep 23, 2013

Just tried the above steps using Brackets Sprint 30 and 31 on Mac OSX 10.8.5. OSX treats each sprint build as an entirely separate product. As a result, so long as I have 30 installed and set as my default "Always Open With" application, then OSX launches 30 when I dbl-click on an associated file, regardless of whether 31 is installed or not. When I delete 30.app, then dbl-clicking a previously associated file, now launches the previous default application that I had on my machine (in this case it was Dashcode). This happens regardless of whether 31 was installed or not.

As a result, I think OSX behaves logically, so long as we consider each Brackets sprint build to be considered as a separate application, with regards to "Open With" file association. However, this could certainly be improved if we move to in-place upgrades as @gruehle @njx and @peterflynn suggest. Doing so should probably allow an upgrade to maintain any existing, already set "Open With" associations -- of course, we'll need to verify that just to be sure that whatever heuristic Finder uses, still works with the upgraded .app files.

@njx
Copy link
Contributor

njx commented Sep 23, 2013

Removing milestone since we will likely be doing in-place upgrades soon.

@peterflynn
Copy link
Member Author

Pretty sure this was fixed by the in-place upgrades implemented in Sprint 34. Closing unless we hear otherwise.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants