Enable file links when task terminals complete

[kenneth-marut-work]

Signed-off-by: Kenneth Marut [email protected]

What it does

Fixes #9677 by ensuring that the terminal-linkmatcher-files's getValidate method does not fail when trying to retrieve the TerminalWidget's cwd field when a task is terminated. This is done by adding a lastCwd field on the terminalWidget which is set every time a taskTerminal is started or reused.

I've added this fix on the frontend although the underlying issue is due to the base-terminal-server's call to this.processManager.get(id) being prone to failure when tasks end (i.e. 'terminal "id" does not exist').

How to test

• Before pulling this branch, open Theia's master branch and build.
• Open Theia to a workspace with some files in it
• Add a task in your workspace that looks something like:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "list filepaths",
      "command": "find $(pwd)",
      "type": "shell"
    }
  ]
}

• Run that task and observe that you cannot ctrl+click on the file paths

• Run the command find $(pwd) manually in a separate Theia terminal and observe that you can click the paths

• Exit Theia, and build this branch

• Run through the same steps and observe that paths are now clickable even after the task ends.

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[rcla]

@kenneth-marut-work

With the initial changes proposed by you, solve this problem that I have had: (Thanks)
Firing up a Task

However with the last proposed change "switch ordering of fallback"
The same problem appears again

[vince-fugnitto]

I confirmed that it fixes the issue with file links in terminals when executing tasks 👍

[kenneth-marut-work]

@rcla

With the initial changes proposed by you, solve this problem that I have had: (Thanks)
Firing up a Task

However with the last proposed change "switch ordering of fallback"
The same problem appears again

Thanks for bringing attention to this issue. The behavior you've described does make sense with the ordering change since prior to the last commit, the backend method was never being called and thus never triggering the error (which is just hiding the underlying issue). Unfortunately, though the original commit did prevent the error from being thrown, it's probably not in the best interest to revert that change since I'm relying on the error being thrown to allow for the fallback inside the catch block.

Maybe a potential fix for the future is to make these errors less invasive and to use warnings instead, however I think it may be out of the scope of this MR since several features of the task/terminal system likely rely on these errors.

[colin-grant-work]

Thanks for addressing my comments. I agree that this likely isn't the place to modify the behavior of the backend error logs: the faulty logic to which they point still exists. The code here allows the frontend to work around the possibility of backend failure, and that's a step forward.

[rcla]

@kenneth-marut-work @colin-grant-work

Thanks for the explanations, now I understand what concerns the backend errors for the future in another PR.