But it should also be smart enough not to present a tiny box when the formula is already very large. E.g. the last example from
https://www.mediawiki.org/w/index.php?title=VisualEditor:TestMath&oldid=749189&veaction=edit

Otherwise the user will need to resize the box on every formula of some pages

Cross-posting from previous bug

@Richard/others: Thinking about making the dialog draggable and resizable...

The solution I initially think of is installing jquery.ui and then adding some
parameters to OO.ui.Window that allow it to be made resizable and/or draggable.
However, if I recall correctly one of the principles of OOJS was to be
self-contained... so would this be wrong? Could someone else with a bit more
firsthand experience chime in here?

Just to note I'm just an end user, so don't really know much about how the Visual Editor code works. It might be an idea to consult with the VE people for the best way to achieve this. I've not found any other VE dialog which is movable or resizable, so I'm not sure if there is code you can copy.

What is really important is that the box is big enough. Following from Helders comment you could detect the size of the original equation and size accordingly.

What might also be possible would be to detect if the equation is inline or a block mode. (In the tex world this would be $eqn$ vrs $$eqn$$) a larger edit window is preferred for block mode equations. Its a little tricker to detect the difference in wikitext, suronding text on the same line indicates inline mode. Being a single item in a list element <li><math> ...</math></li> indicates block mode.

(In reply to comment #3)

Just to note I'm just an end user, so don't really know much about how the
Visual Editor code works. It might be an idea to consult with the VE people
for
the best way to achieve this. I've not found any other VE dialog which is
movable or resizable, so I'm not sure if there is code you can copy.

See bug 49969 (and maybe bug 49549).

(...)
What might also be possible would be to detect if the equation is inline or a
block mode.

See bug 12223.

Change 97750 had a related patch set uploaded by Catrope:
Fix moving over an image with the arrow keys in Firefox

https://gerrit.wikimedia.org/r/97750

(In reply to comment #5)

Change 97750 had a related patch set uploaded by Catrope:
Fix moving over an image with the arrow keys in Firefox

https://gerrit.wikimedia.org/r/97750

Mis-targeted, sorry!

I'm still trying to get a Google Code-in task or more out of these VE Math plugin reports...

If I understand the comments, the "movable" part can't be fixed for this plugin because it depends on VE's current capacity to do so (bug 49969), right?

Can the size of the window be controlled? If so, could this be a GCI task?

Re-positioning of OOjs UI windows is a really major piece of work, yes.

Re-sizing is very do-able, however.

physik wrote:

Can someone look at https://gerrit.wikimedia.org/r/#/c/105647/ ... It would be great to merge this before it has to rebased manually again.

physik wrote:

Change was merged. Seems to be fixed.

This is only done for auto-resizing and auto-positioning, not manual resizing and positioning ("dragging") which this bug is asking for (and which depends on bug 49969). Reopening.

The second point in this task is really annoying when working with large equations; The dialog is too small to see the whole source text of the equation.

Workaround is to use the plain old editor, but then it is easy to do an error and the whole equation bombs out.

https://ux.stackexchange.com/questions/81134/should-modal-dialogs-be-movable seems to show a (rough) consensus that when a proposed solution to a dialog is to make it moveable, the dialog itself is poorly designed. That implies looking for a different solution that addresses the underlying user problem.

In T59437#5658604, @John_Broughton wrote:

https://ux.stackexchange.com/questions/81134/should-modal-dialogs-be-movable seems to show a (rough) consensus that when a proposed solution to a dialog is to make it moveable, the dialog itself is poorly designed. That implies looking for a different solution that addresses the underlying user problem.

See discussion of this in T51969

In T51969 TrevorParscal write

The idea of the dialog being modal is that you aren't multi-tasking with it at all.

There is a question as to whether a modal dialog is appropriate here or a modeless dialog. A typical modal dialog would be password entry which must happen before continuing.

Here we are multi-tasking editing an equation is a subtask of the job of editing the whole page. You do want to switch back and forward to see how changing the equation will affect the look of the whole page. To me, the use-case suggests a modeless dialog is appropriate here.