Make dialogs movable and sizable.

[dpvc]

This PR adds the ability to move and resize the dialog boxes used in MathJax, like the "Show Math As ..." output and the explorer help dialog. (This was requested in mathjax/MathJax#3411).

To do this, it creates a new DraggableDialog class and several subclasses for handling dialogs. These are used instead of the current Info and SelectableInfo classes from mj-context-menu. While it would have been possible to modify the menu classes, I didn't want to have the dialog boxes be dependent on the men code, since, for example, the explorer help dialog would then be dependent on having the menu code, and I thought they should be independent. The one complication was the Clearspeak preferences panel, where I grafted the new code onto the existing SelectionBox implementation via a subclass. This is a bit of a hack in order to get access to the layout mechanism implemented in SelectionBox. I think it would be guid to revisit the menu code sometime soon, and plan to clean up that situation at that time, so this is a "just for now" hack.

The main dialog code is in ui/dialog/DraggableDialog.ts, which uses the dialog HTML element when possible, as in #1334 (and this PR supersedes that one). It adds drag areas along the edges and at the corners for sizing the dialog and makes the remainder of the grey frame be the drag areas for moving the dialog. The dialog now centers horizontally and vertically automatically (whether it uses the dialog element or not), and the handling of maximum widths and heights is improved over the current setup.

The CSS for the help dialog has been moved largely to the DraggableDialog class, with help-specific CSS moves to the creation of the help dialog in the help() method of the KeyExplorer. The help message creation function and platform data are moved to static properties of the KeyExplorer (so they can be made available to subclasses or customizations, if needed). That makes the diff a little convoluted around that, so this is just a heads-up about that.

The help() method is changed to basically just be a call to the InfoDialog subclass of DraggableDialog. Note that this allows setting of styles specific to the dialog, and so some of the CSS has been moved here, while the code for creating the dialog has been moved to DraggableDialog.

The menu code that used to use Info and its own SelectableInfo subclass has been modified to use InfoDialog and CopyDialog instead. That includes the Annotation menu and the Clearspeak preferences dialog. The SpeechMenu.ts changes are to use the new SelectionDialog rather than SelectionBox. I added a few type definitions to make that a bit easier. The SelectionDialog is actually a subclass of SelectionBox for now, so that it can access the existing layout and event methods; it calls InfroDialog to create the actual dialog itself when posted. I did have to copy most of the display() method in order to avoid it calling super.display(), however, and because most of the methods are private rather than protected, I had to cast to any in order to call them. Again, that can all be straightened out when the menu code is revisited.

The Annotation menu actually wan't working as it didn't include the needed callbacks, so it never became active. I've fixed that here as well.

The changes to MJContextMenu.ts are to create the new type definitions, and to only try to unpost if it is actually posted (this is to avoid an error when selections are made in the Clearspeak preferences panels, which try to unpost the main menu, even though it is not posted).

The changes in Menu.ts are mostly to change from using Info and SelectableInfo objects to using the new InfoDialog and CopyDialog classes. A few of the dialogs are augmented, however. The About dialog now lists all the packages that have been loaded and their versions (like in the old v2 about box), and the SVG Image dialog now formats the output so that it is more readable. The code that attaches the info boxes to the menu is no longer needed, and the formatSource() method is moved to the CopyDialog class. Some of the SVG code is simplified (using async functions and awaitrather than explicit.then()calls). Finally, the default Zoom Trigger is set to useAltrather than nothing, since plain clicking and double-clicking both are used to activate the explorer now, so a modifier key is needed for zooming unless the explorer is disabled. TheSelectableInfo.ts` file is removed, since it is replaced by the CopyDialog class.

The CopyDialog class subclasses the InfoDialog class, overriding its HTML creation function to always add the "Copy to Clipboard" button, and to add a code option that causes the dialog text to be formatted as source code (escaping the HTML special characters) and wrapped in a pre element.

I'm hoping the DraggableDialog code is commented enough to make it clear. If not, let me know and I can explain further.

Currently, I've added the DraggableDialog and InfoDialog objects to the core component, so that both the menu and explorer code have access to them. It would be possible to make a separate component for these and have the menu and explorer code have that dialog component as a dependency. I'm not sure which approach is better. The current one doesn't change the number of files that need to be downloaded, but makes the core component larger when the dialogs may never be needed. But making a separate component means an additional download in the case where individual components are loaded. Since most people use one of the combined components (like tex-mml-chtml), and these include both core and the menu and explorer code, it won't make a difference to most users; it only affects loading individual components in a custom setup, or those building their own combined component (who would need to preload an additional component). Any thoughts on that?

This resolves issue mathjax/MathJax#3411, as well as mathjax/MathJax#3405.

[codecov]

Codecov Report

❌ Patch coverage is 64.39067% with 412 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.36%. Comparing base (afaf1ea) to head (1135887).
⚠️ Report is 89 commits behind head on develop.

Files with missing lines	Patch %	Lines
ts/ui/dialog/DraggableDialog.ts	63.37%	408 Missing ⚠️
ts/ui/dialog/InfoDialog.ts	90.69%	4 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1357      +/-   ##
===========================================
- Coverage    86.72%   86.36%   -0.36%     
===========================================
  Files          337      340       +3     
  Lines        84145    85541    +1396     
  Branches      3140     3150      +10     
===========================================
+ Hits         72971    73876     +905     
- Misses       11174    11665     +491     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dpvc]

I've added some commits to handle moving and sizing via the keyboard, and a help button to get a dialog that explains how to interact with the MathJax dialogs via mouse and keyboard.

[dpvc]

When I closed the original help dialog PR, I forgot that it included the ability to disable to help dialog, which was not in this PR, so I cherry-picked that commit to include that here, as the other PR has been closed without merging.

[dpvc]

I added a commit that tweak the help and close icons to look better across platforms (in particular on Linux). It also fixes a problem with the height of the dialogs in Safari (they were being made 0 height) by removing height: 100% that wasn't needed and was causing problems. Finally, it fixes a problem with opening the help dialog from the About MathJax dialog where the wrapping was disabled.

[zorkow]

Very nice, just a couple of minor things:

• When I drag very quickly with the mouse, sometimes the mouse pointer is faster than the dialog box and I "loose" the box.
• The meta key can be quite overloaded with functionality by the of the OS/Windows manager. For example, I could not get shift meta to work. I am wondering if we should not swap Alt and Meta. I feel moving is more important than resizing.
• If I leave the page in the browser with go back or go forward, the dialog box stays visible. Is that intended?
• Finally, let's keep the as part of the main components. As you said most people won't even notice since they use the full bundle anyway.

[dpvc]

• When I drag very quickly with the mouse, sometimes the mouse pointer is faster than the dialog box and I "loose" the box.

I'm not able to reproduce this either in MacOS or Linux, but my linux is in a VM, so that might affect the results. By "loose" do you mean that the box stops moving and is left where it last was moved, or does it mean that it continues to move, but the pointer is now in a different location on the moving box, compared to where you first clicked it?

• The meta key can be quite overloaded with functionality by the of the OS/Windows manager. For example, I could not get shift meta to work. I am wondering if we should not swap Alt and Meta. I feel moving is more important than resizing.

OK, I will switch their roles. It is true that the arrow keys with modifiers are overloaded a lot. The other option I had considers was to use a start-move (like "m" or "alt-m") and then normal arrows keys would move, with escape (or maybe any other key) ending the moving. Similarly, "s" or "alt-s" could start sizing. I think that is more awkward, but for the mobility impaired, it might be better to not have to hold two keys at once.

If I leave the page in the browser with go back or go forward, the dialog box stays visible. Is that intended?

Well, I didn't think of the dialogs as all that ephemeral that they would disappear on their own. But I suppose I could add a visibilitychange listener to close the dialog in that case. Do you think that would be better?

Finally, let's keep the as part of the main components. As you said most people won't even notice since they use the full bundle anyway.

OK, sounds good.

[dpvc]

I've tried out the visibilkitychange handler, and it does work for this, but although the dialog close action is taken when you leave the page by going forward or backward in the history, it doesn't actually update the display until you come back to the page (at least in Firefox), so you see the dialog briefly when you come back before it disappears. Not the best look. If I can't find something better, I'd be inclined to leave it open (that is, leave it as is).

[dpvc]

It turns out it is a problem for Firefox only when the developer's console is open, so I'm OK with making the change after all.

So it is just a question of whether to use start-move and start-size key rather than alt and meta keys.

[dpvc]

I've pushed commits that add the move/size toggle that I suggested above (with additional information in the help dialog), plus implements the visibilitychange event listener to close the dialog when the user views a different page. (We can add that to the menu later.)

I also updated the explorer help dialog to include a more explicit statement about how to turn it off. We have gotten several requests to disable the info icon or highlighting, and I'm trying to persuade them not to do that, and one argument is to say that sighted people can more easily make the menu changes needed to turn it off than the blind can turn them on, so if the instructions are more explicit, that supports that argument.