Open TristanBrotherton opened 5 years ago
Thanks for the report -
I am unsure of which specific version of Atom this behavior stopped working, but it was recent.
How recently did this work? That might helping testing particular versions to see where this worked and stopped working
And just to clarify your repro steps, you need to have a project open that has a templates/styles.css
file off of the root of the project before clicking the example link?
I'd say the last couple of months. I can spend some time trying older versions of Atom if it is helpful. Prior to that it has been functioning since at least Nov 20, 2018 - which is when I wrote the extension that was using this call.
Yes - to clarify the repro steps the project is open, and contains a file by the path specified.
I have not done an exhaustive test but I can confirm that Atom 1.36.0 will open relative paths as expected so it was broken by a release after that.
Thanks for checking, I was poking around too and it looks like 1.36.1 might be where the problem started. I started Atom in the foreground with atom --foreground
and when trying to reproduce, I see this in the terminal after clicking one of those open links:
2019-07-31 20:46:17.836 Atom[70418:2607446] stat.isFile is not a function
2019-07-31 20:46:17.837 Atom[70418:2607446] TypeError: stat.isFile is not a function
at win (/Applications/Atom.app/Contents/Resources/app.asar/src/core-uri-handlers.js:27:18)
at bestWindow.getLastFocusedWindow.win (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:1234:76)
at Array.find (native)
at WindowStack.getLastFocusedWindow (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:1666:25)
at AtomApplication.getLastFocusedWindow (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:416:29)
at AtomApplication.openPackageUriHandler (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:1234:25)
at AtomApplication.openUrl (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:1225:19)
at App.disposable.add.ipcHelpers.on (/Applications/Atom.app/Contents/Resources/app.asar/src/main-process/atom-application.js:612:12)
at emitTwo (events.js:126:13)
at App.emit (events.js:214:7)
To confirm, I git-blamed that first line mentioned in the stack trace back to https://github.com/atom/atom/pull/19169 which looks like it landed in 1.36.1 I think.
Is there a chance this might get resolved in the near-term, or should I rewrite my packages to expect absolute paths (seems like the wrong thing to do).
I don't believe this would get resolved in the near-term unfortunately - if someone in the community opened a well-written pull request to address the problem that would be helpful, though we couldn't promise a specific timeframe for when it would get reviewed in that case.
Prerequisites
Description
URI handling used to support opening files via a project specific path. IE the path given to a file by right clicking and selecting "copy project path". I am unsure of which specific version of Atom this behavior stopped working, but it was recent.
Steps to Reproduce
Example (in an external webpage):
Relative path - does not work. (used to work)
<a href='atom://core/open/file?templates/styles.css'> link </a>
Absolute path - does work.
<a href='atom://core/open/file?/Users/username/Documents/folder/templates/styles.css'> link </a>
Expected behavior:
Relative paths to open files as they used too in previous versions
Actual behavior:
Atom is focused, but no file opens
Reproduces how often:
100%
Versions
1.39.1
Additional Information
This breaks various chrome plugins that use the source maps to open the original file.
Edit by @rsese: from https://github.com/atom/atom/issues/19723#issuecomment-517093132:
Thanks for checking, I was poking around too and it looks like 1.36.1 might be where the problem started. I started Atom in the foreground with
atom --foreground
and when trying to reproduce, I see this in the terminal after clicking one of those open links:To confirm, I git-blamed that first line mentioned in the stack trace back to https://github.com/atom/atom/pull/19169 which looks like it landed in 1.36.1 I think.