Adds a "Show in file browser" entry in tab context menu

[telamonian]

Fulfills the request made in #4472. Adds a "Show in file browser" entry to the context menu for tabs. Clicking on this menu item will activate the file browser pane and select the currently active file.

One weakness is that it will only work with the currently open file, even if you right click on another tab. However, this seems to be a flaw in the context menu itself (since the same thing happens when you select "Rename...") rather than my patch.

I'm not particularly familiar with JS or TS, so if there's anything basic (style, spacing, etc) I should fix, please let me know

[jasongrout]

The focus issue is probably because the app's current widget app.shell.currentWidget doesn't change apparently by right-clicking on a tab.

[ian-r-rose]

@jasongrout Yeah, I also left a comment about this in #4472. We may need to think some of the handling of the universal context menus, as dispatching entirely based on CSS selectors may not be enough information.

[telamonian]

Some integration tests are failing, but I'm not entirely sure what the problem is, or even if there is one. AppVeyor ran one test successfully, hung and timed out in the middle of the second, and then cancelled the third.

Should I be concerned? Or is this SOP for AppVeyor?

[ian-r-rose]

Thanks @telamonian, this is looking good.

One thing that this won't work for: if the user has any file browsers installed that are not the main one (for instance, the Google Drive or GitHub browsers), 'navigate-main' will not be able to find them. It should be possible to also make this function work for those, but it would take some more work. We could try to do that here, or in a follow-up later.

[ian-r-rose]

Typically this command won't be executed if isEnabled is not true, so this check is redundant.

[ian-r-rose]

If the current widget is not a document, the context object will be undefined here. We should probably return without any action in that case.

[ian-r-rose]

Also, I think the test failures were spurious. I have restarted the tester.

[telamonian]

So, I worked out a fix for the tab focus issue. It's completely robust/reliable (at least in my own testing), though it does smell a bit.

Basically, JupyterLab objects will now capture the most recent contextmanager Event in a contextEvent property. The code in the showInFileBrowser command can then inspect contextEvent.target in order to find the path information it needs.

Annnd, while I was uploading it I now see there's a code review. Whoops

[telamonian]

I rolled back the focus fix (since I think it's complex/messy enough to need its own PR) and applied the requested changes.

[ian-r-rose]

Thanks @telamonian. I think we probably want to think through a bit more how to handle the context-menu/active-widget problem, so I don't view that bug as a blocker for your PR. That was a clever solution, though!

[ian-r-rose]

I think docManager.contextForWidget returns undefined if it doesn't find the context (thanks, Javascript, for having two falsy values!). We can check for both by doing if (!context)

[telamonian]

I'll change it. I was under the impression (from the three seconds of reading docs that I just did) that if (x == null) tests for both null and undefined (unlike if (x === null) which is "strict" and only tests for null). Do you know if that's correct?

[ian-r-rose]

Ah, you may be right. We usually try to avoid the coercive == just to avoid these types of confusions :)

[ian-r-rose]

Thanks @telamonian, this works great!

[ian-r-rose]

We can fix the focus issue in a follow-up, once we decide to proceed.