atom / atom

:atom: The hackable text editor
https://atom.io
MIT License
60.11k stars 17.41k forks source link

URI handling no longer supports project specific pathing. #19723

Open TristanBrotherton opened 5 years ago

TristanBrotherton commented 5 years ago

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:

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.

rsese commented 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?

TristanBrotherton commented 5 years ago

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.

TristanBrotherton commented 5 years ago

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.

rsese commented 5 years ago

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.

TristanBrotherton commented 4 years ago

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

rsese commented 4 years ago

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.