[pulsar-next] Cannot read properites of null while reload & dev console focused

[asiloisad]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

It looks like workspace is destroyed to early if dev tools is focuesd.
It looks like View Registry send update after atom.workspace is destroyed

Pulsar version

1.124.2025021423-next

Which OS does this happen on?

🪟 Windows

OS details

10

Which CPU architecture are you running this on?

x86_64/AMD64

What steps are needed to reproduce this?

1. Open Pulsar
2. Open any file (e.g. README.md)
3. Open Dev Console / Console
4. Make sure "Preserve log" is ticked and focus input line of Console
5. Ctrl-Shift-F5

Additional Information:

No response

[asiloisad]

It look like a simple guard fix this: src/view-registry.js -> performDocumentUpdate() -> add first line if (!atom.workspace) { return; }. I'm holding off on doing PR because I have doubts whether it's the correct solution to this problem.

[savetheclocktower]

So the only way to trigger this is to have focus in the developer tools console while triggering the window reload?

I suspect that this is happening because performing that key combination while the dev tools are focused triggers reload through conventional means, rather than through our Window: Reload command. If you can type location.reload() in the console and observe the same symptom, then that'd confirm it.

If I'm right about the cause here, then I don't think it's a bug. I think it's plausible that a certain amount of environment cleanup is triggered by the Window: Reload command, but isn't listening for a beforeunload event (or any of the other similar events for this situation) because it doesn't envision a reload being triggered by any other means.

It's possible we could do this the “correct” way and have all our cleanup behavior downstream of the actual request to reload the page, but not certain. For instance, if we have to do any asynchronous cleanup work, then it's probably better for us to perform that work, await the result, and then call location.reload() (as I believe the Window: Reload command eventually does internally).

If I'm not right about the cause, then I wasted a few minutes of my life typing these words.

[asiloisad]

location.reload() is a bit worse. I have confirmed that Ctrl-Shift-F5 isn't going to use atom.reload() by implement logger there.

I have tested atom.commands.dispatch(atom.workspace.element, 'window:reload') too, then editor crashed every time.

[savetheclocktower]

I have tested atom.commands.dispatch(atom.workspace.element, 'window:reload') too, then editor crashed every time.

Oof! OK, then the root cause is something else. I'll take a look.

[asiloisad]

Oh sorry, I have tested it more and atom.commands.dispatch(atom.workspace.element, 'window:reload') going to random crash only (not every time).

[savetheclocktower]

Oh sorry, I have tested it more and atom.commands.dispatch(atom.workspace.element, 'window:reload') going to random crash only (not every time).

If it's a literal crash, hopefully that's just #1215 rearing its ugly head? Or have you updated since that fix?