Page MenuHomePhabricator

OOUI: Dialogs should be repositionable/draggable
Open, LowestPublic

Description

Problem

There are various workflows where a user wants to both interact with (or at least see) a page's content, and also interact with a potentially complicated form/process, which may have many controls/inputs.

Some VisualEditor examples:

  • Adding/editing categories (T51969#548266)
  • Adding/editing a template with many parameters

Some non-VE examples:

Feature request

Dialogs that have no need to be modal (intended to interrupt the primary workflow, and requiring some action before you can get back to the primary workflow) should be draggable.
Gadget/script/other developers using OOUI should have a simple way to enable this feature, e.g. a config setting that can be set to true to allow dragging.

Some specific workflows may have viable alternatives to dialogs, e.g. T52239: VisualEditor: Allow the user to edit categories at the bottom of the page, similar to HotCat, but that doesn't solve the general problem for more complicated dialog-based workflows.

Initial task description

Quoth requester: If I can't read the article, because the "page settings" box is large and un-draggable and hides all the article, how can I see what defaultsort or categories I want to add (especially as for defaultsort I probably want to copy and paste all or part of the article title).

Details

Reference
bz49969

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:49 AM
bzimport added a project: OOUI.
bzimport set Reference to bz49969.

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

As far as adding a category or changing the default sort of a category directly from some other mode (such as reading, or editing paragraph text) we should look at those workflows rather than dissolve the intentional model-ness of the dialog.

For example:

  • Perhaps categories could be edited at the bottom of the page, rather than inside a dialog.
  • Maybe the category editor could use some other kind of UI container that isn't modal.

etc.

(In reply to comment #1)

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

This isn't asking for multi-tasking, it's asking for the ability to drag the dialog out of the way so that you can get context for the single-tasking, err, task. :-)

If I want to add "Category:1917 births" and "Category 1987 deaths" to an article, is it undesirable multitasking to expect to be able to see the lead sentence which says "'''Joe Bloggs (1917-1987)...", rather than having to remember the two dates? Or if I want to assign "Category:Villages in ..." for some area whose placenames are unfamiliar and have difficult spellings? Please let me see the article while adding categories: a simple way would be to let me drag, or shrink, the dialogue box which at present totally obscures the article text. (I was the original reporter of this bug on 21 June, and the response above seems to misunderstand its importance.)

Any movement on this? Low-priority according to the development team, I accept, but it's a pretty important chunk of the editing workflow for a lot of tasks.

How hard is it to make the dialog box moveable? Really? There is what, one parameter that needs to be changed? If this were a really hard problem, it would be understandable that the VE team was deferring this for more important things. But it's not that hard (I hope; if so, that bodes poorly for VE), and it impacts LOTS of editors. Yes, it affects the dialog box for page settings, when doing categories. But there is the identical problem when adding a caption for an image (Media settings dialog; might want to know how something in the article is spelled) and possibly for the other dialog boxes (for example, in the Media dialog, searching for an image where the search term has an unusual spelling).

Even better would be the ability to copy/paste from the main editing window to a field in the dialog box. I realize that has potential ramifications for loss of focus - it would be undesirable for the dialog box to disappear *behind* the main editing window. Still, in Mac OS X, the "Force Quit Applications" dialog box is moveable, and the user is able to copy text from other windows, but the dialog box remains on top of every window until it is closed. (Excessive, actually: the ideal is to have the VE dialog box float on top of the main editing window, ONLY.)

But we (as in, Wikipedia editors) would settle for a really minimal solution, initially - just make the dialog boxes moveable. Please?

Six weeks on from first request it's depressing to see this is still "low enhancement". Example: stub-sorting a Russian icehockey player, I open the dialog box to remove the existing stub tag and then go to the dropdown menu to add "Russia-icehockey-bio-stub", only to discover that there are separate stubs for wingers, goalies, etc. I didn't notice what he was. I have to quit the dialog box, find he's a winger, re-open it, re-delete the old stub, return to the dropdown menu to add the new stub template. The inability to move or shrink the dialogue box makes ordinary routine wikignoming harder work. But I suppose the target market of newbies don't do things like that, and we established editors can be trusted to struggle on regardless (some of us, perhaps a diminishing number), however ignored our needs may be?

Yes, I could abandon VE and this wouldn't trouble me any more, but I'm trying to help by persevering in using it to help you debug it. In return, how about a little attention to one of the first issues I raised?

Prioritisation of work is done on how much it interferes with people using the software, not how long ago it was first mentioned as an issue. For example, bug 4 (!) is from 2004.

I'm sorry that this is getting in the way of your use of VisualEditor, but I think that adding copy and paste support (for example) should happen first. I could "upgrade" the importance of this to "high" but it wouldn't get the code written any faster. :-(

Two months since there's been any comment on this ... I admit I've pretty much given up using VE (too tedious because of this and other problems, plus some stuff going on in Real Life which makes me want to reduce Wikistress). Any chance of it getting fixed some time? I'm sure I'm not the only person affected.

(In reply to comment #9)

Two months since there's been any comment on this ... I admit I've pretty
much
given up using VE (too tedious because of this and other problems, plus some
stuff going on in Real Life which makes me want to reduce Wikistress). Any
chance of it getting fixed some time? I'm sure I'm not the only person
affected.

Some time? Yes. Soon? No. In my view, it's not as important as fixing things like copy-and-paste or adding citation template quick-add support or editing tables.

Let me know when this is fixed, because I'm not going to stress myself by using VE until then - it just makes my everyday editing too much like hard work. When it's fixed (and perhaps a few more of my long-standing complaints - hidden comments, red links appearing as red, etc), I might carry on with debugging your system. Till then, why should I bother?

Understandable. You will receive a bugmail notification once this bug report is fixed.

The change review window is also too small to be useful for some editors, especially if a lot of changes have been made.

Moving to the OOjs UI product as that code is now shared.

  • Bug 67952 has been marked as a duplicate of this bug. ***

Why is this languishing at low priority? Fixing something that is preventing the editor from reading the thing he is editing is HIGH priority.

(In reply to Spinningspark from comment #17)

Why is this languishing at low priority? Fixing something that is preventing
the editor from reading the thing he is editing is HIGH priority.

"High" priority would mean that it's more important than editing tables, editing in Chinese, or editing galleries. "High" priority is not appropriate for this relatively minor and very complex enhancement request.

Just to be clear, this is a DESIGN TEAM problem, because it's a problem with the OOjs UI, which VE uses, but which is under the control of the Design team. The issue is that the OOjs UI WindowManager lacks a resizing event. That issue affects every use of windows in the OOjs UI, not just VE's use of windows.

Why isn't this bug showing on the list of problems that the Design Team is considering (https://bugzilla.wikimedia.org/buglist.cgi?keywords=design&keywords_type=allwords&list_id=335932&order=changeddate%20DESC%2Cvotes%20DESC%2Cpriority%2Cbug_status%20DESC%2Cassigned_to%2Cbug_id&query_format=advanced&resolution=--- )? (I got that list via https://www.mediawiki.org/wiki/Design )

Relatedly, why is the priority for fixing this bug being set by the VE team, rather than by the Design team?

(In reply to James Forrester from comment #18)

(In reply to Spinningspark from comment #17)

Why is this languishing at low priority? Fixing something that is preventing
the editor from reading the thing he is editing is HIGH priority.

"High" priority would mean that it's more important than editing tables,
editing in Chinese, or editing galleries. "High" priority is not appropriate
for this relatively minor and very complex enhancement request.

You can't edit anything, tables, Chinese or galleries, if there is big immovable box in the way.

You can't edit anything, tables, Chinese or galleries,
if there is big immovable box in the way.

This isn't really true: you can close the box. With the box open (and movable), you can *see* the content on the page, but you still can't edit it. When you've got a dialog box open, but all your typing ends up on the page underneath the box, then we call that a bug.

The problem here is that (depending on the size of the box and the exact location of your cursor when you open it), what you need to *see* on the page might be covered up by the box. "Open box, realize that you've forgotten how to spell something, realize that the box is covering up that word, close box, check spelling, open box again, finally type" is not as efficient as "Open box, drag it out of the way, start typing".

I would like to avoid adding moving and resizing to dialogs, because I believe it solving the problem in the wrong way. At it's root, this is a workflow problem. Making the dialog resizable and movable does not adequately address it.

More of these processes should be non-modal, especially authoring edit summaries. This would allow users to contribute to edit summaries as they work, rather than having to write them at the very end, when the changes they've made are so temporally distant.

Even if the dialog is movable an resizable and movable, the contents below are only visible through a semi-opaque mask and the contents cannot be scrolled because the modal dialog is capturing events (on purpose, it's modal).

(In reply to Trevor Parscal from comment #22)

I would like to avoid adding moving and resizing to dialogs, because I
believe it solving the problem in the wrong way. At it's root, this is a
workflow problem. Making the dialog resizable and movable does not
adequately address it.

More of these processes should be non-modal, especially authoring edit
summaries. This would allow users to contribute to edit summaries as they
work, rather than having to write them at the very end, when the changes
they've made are so temporally distant.

Even if the dialog is movable an resizable and movable, the contents below
are only visible through a semi-opaque mask and the contents cannot be
scrolled because the modal dialog is capturing events (on purpose, it's
modal).

This is a good point, but I dont think, its related to this enhencment. You are right, that if I am doing a lot of different changes and/or editing the article several minutes, I forgot, what I was doing. But how this problem is related to the fact, I cannost drag the DW avay to see what is behind?

(In reply to Trevor Parscal from comment #22)

I would like to avoid adding moving and resizing to dialogs, because I
believe it solving the problem in the wrong way. At it's root, this is a
workflow problem. Making the dialog resizable and movable does not
adequately address it.

....

You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

If I want to add a stub template for a Russian footballer, and then discover that not only do I need {{Russia-footy-defender-stub}} but that it's subdivided by date of birth, I need to be able to look at the article and find his date of birth to use {{Russia-footy-defender-1960s-stub}}. If I want to add a defaultsort, I need to be able to copy the surname, and then the forename, from the text of the article. How should I adjust my workflow?

For the foreseeable future, I've adjusted my workflow by abandoning any attempt to use VE as it makes my editing too difficult.

I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)

You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Here's a rough mockup – note the docking icon on the right. Thoughts?

2014-12-05_16_03_11-Developer_Tools_-_http_en.wikipedia.beta.wmflabs.org_wiki_0.24595949980612886_.png (683×1 px, 113 KB)

...and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Even if the dialog window is very large, it can still be pushed out of the way by dragging it until it is nearly completely off screen.

Indeed, but in this use case you then have to drag it back on-screen to input the category name or whatever.

matmarex set Security to None.

Looks as if it might work: I don't know the term "dock" but I think you mean what I'd call "minimise"? So click on that icon, the dialog box shrinks to an icon, I read what's behind it: I hope I can copy text from it, eg to fix a DEFAULTSORT? Then click on the icon to restore the dialogue box and carry on. Yes, could be a great solution. Probably better than my original suggestion, many moons ago, of dragging or resizing. Thanks.

In T51969#821594, @PamD wrote:

I don't know the term "dock" but I think you mean what I'd call "minimise"?

No, dock does not mean the same as minimise. Docking is fixing the dialogue to one edge of the window, rather than plonking a popup in the middle of the window. In the mockup example the dialogue is docked to the bottom of the window. Applications often give the user a choice of which edge they want to dock to, but I don't know if that is what is propsoed here.

For me, this would work if the window could still be scrolled while the dialogue was open, thus uncovering any content hidden by the dialogue (or even off the boundary of the window at the time the dialogue was invoked).

The discussion is complicated by the unnecessary "Options" menu on the left side of the dialog box. (I believe this is the only place in VE where selecting a choice from a top menu results in a dialog box that shows all the other choices on that menu; that would make sense if an editor were likely to want to do two or three page-related things at once, but in fact he/she almost certainly does *not*.) While redoing the entire approach to how the three-line (should be "Page") menu choices work is probably outside the scope of this topic, I will note that what the requester needs (access to all the text on the page, *while* the dialog is open) is applicable only to two choices - categories and default sort.

For those two menu choices, categories and default sort, I suggest that the dialog attach itself to the right side of the window, taking up 1/3 of the width of the window, and that the left side - the text on the page - be scrollable. (If it's easier to program, then perhaps the dialog should be attached on the left, with the scrolling done on the right.) For the other menu choices, a normal modal dialog box is fine.

Making the dialog one-third the width of the screen is only going to make sense on a desktop system. One third the width of a smartphone screen is not going to be functional (the entire dialog box would be a couple of centimeters wide).

In T51969#548465, @PamD wrote:

(In reply to Trevor Parscal from comment #22)

I would like to avoid adding moving and resizing to dialogs, because I
believe it solving the problem in the wrong way. At it's root, this is a
workflow problem. Making the dialog resizable and movable does not
adequately address it.

....

You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

I am not saying it's a problem with YOUR workflow, I'm saying it's a problem with the workflow we are providing you. I'm admitting we have failed you, and because we didn't understand how you actually use the software we modeled the workflow around our imagined way you might use the software.

In my view, editing categories should not be a modal experience. The category editor should simply be embedded at the bottom of the page in place of the category listing. If we do anything to try and get the dialog out of the way temporarily, we will still not be able to let you select text behind the dialog without breaking the entire concept of a modal dialog. By placing the category editor at the bottom, you are free to scroll around and select whatever you like. This is the experience you have with the Wikitext editor, and there's no reason we can't continue to provide it.

In my view, editing categories should not be a modal experience.

Not necessarily modal. The HotCat gadget that this partially replaces is already effectively-modal too, for instance.

The category editor should simply be embedded at the bottom of the page in place of the category listing.

That's T52239: VisualEditor: Allow the user to edit categories at the bottom of the page, similar to HotCat.

I'm increasingly convinced that draggable dialogs in general are a solution in search of a problem. (It could be interesting to do, but shouldn't be applied to all dialogs.)

You're saying that I've got a problem with my workflow: how else do you suggest that I add a category, a stub template, or a DEFAULTSORT to an article, if I can't read the text of the article? I could copy and paste the entire article content into a notepad, so that I could refer to it ... hardly seems reasonable.

I was thinking, perhaps the dialogs should be "dockable" at the bottom of the screen? Clicking an icon on dialog's title bar would hide the white overlay and dock it, revealing article content. We should think what to do with dialogs that were modal in this case, but I think this approach could work, and could work a lot better than clunky dragging of dialogs (which are often way too large for dragging to make sense, as they would cover most of the content anyway even when dragged aside).

Here's a rough mockup – note the docking icon on the right. Thoughts?

Eurgh. I really don't like the dockable model of modals. It feels like failure. I'd prefer instead that we provide secondary non-modal ways to do things people want to do that isn't modal. As @Whatamidoing-WMF says, this isn't going to work for anyone that doesn't have a huge desktop screen to use.

I agree that the dockable model is trying to modify something where we might better look for alternatives. For example, one way to create a new category might be to highlight some text, then select (say) Insert > Category. That could open a dialog (for example, to allow a different sort key than the default, and to offer the opportunity to create a category if one being created didn't already exist.

This isn't perfect, of course - if a particular category didn't exist (as text) on the page, the user would have to add it, create the category, then delete the unneeded text. Still, maybe it's better, and at least it's something to think about.

matmarex changed the task status from Open to Stalled.Dec 18 2014, 5:59 PM
matmarex removed matmarex as the assignee of this task.
Jdforrester-WMF lowered the priority of this task from Medium to Lowest.Nov 30 2015, 6:36 PM
Jdforrester-WMF added a project: Epic.

I appreciate this discussion happening. It is strange that we are thinking that draggable dialogs create problems, so I will attempt to illustrate it with a use-case. I am trying to write a user script in oojs-ui, and the script work should be similar to the old gadget whose dialog is draggable to expose different parts of the article text in order to perform its assessment.

Here is the gadget documentation and source code: https://en.wikipedia.org/wiki/User:Kephir/gadgets/rater

Here is a screenshot attached, which I also uploaded to Commons and which is found at the gadget documentation page:

2016-12-06-051054_1280x800_scrot.png (800×1 px, 200 KB)

I would like to be able to perform article rating on the new pages queue continuously one after another, and having draggable dialog reduces the working memory (and increases efficiency) of the process about tenfold, as I don't have to hold the article contents in my memory.

Astonishing this is still open. I stopped using VE a year or two back because this and other problems made for an inefficient worklow. Still not time to give it another try I see.

Yes - when someone tells me that VE is usable, I'll have another look at it. If the dialog box still obscures the content, then for my prolific WikiGnoming it's useless. Two years since I raised this, and no progress. Nice to feel appreciated.

I still think something like a split-screen mode would be a better solution for these cases than movable dialogs (see mockup above in T51969#821409).

Three and a half years on from my initial complaint, and as far as I know the Visual Editor is still useless to me, so I don't use it. Let me know when it becomes a useful editing system for people who need to see the original article while adding categories or doing other tasks.

When editing in VE I sometimes have to load a duplicate copy of the page in a new tab so that I can see what I'm doing.

I dislike the split-screen approach as that uses more screen estate than required and divorces the dialog from its context. I wouldn't object to dockable diaglogs appearing like that at the bottom of the screen as an option, but simply being able to move a reasonably sized box around the screen to a convenient point for the task at hand would be vastly superior imo.

When editing in VE I sometimes have to load a duplicate copy of the page in a new tab so that I can see what I'm doing.

I dislike the split-screen approach as that uses more screen estate than required and divorces the dialog from its context. I wouldn't object to dockable diaglogs appearing like that at the bottom of the screen as an option, but simply being able to move a reasonably sized box around the screen to a convenient point for the task at hand would be vastly superior imo.

Yes, that exactly sums up the issues. A moveable window is the best solution. The issue is being clouded with these alternative solutions and we have ended up with no solution at all.

I've implemented draggability for an OOUI process dialog for the latest version of my Rater script, by using a drag-and-drop library and some CSS overrides. It would be nicer if this functionality was directly supported, rather than relying on a library with a bunch of functionality that isn't actually used -- at least for reusers of OOUI, even if WMF devs choose not to use it.

(Coincidentally, this is the exact use-case @Gryllida was describing above three years ago.)

FYI, I found I could do the draggability easily enough without the library, just using mouse/pointer events directly - diff.

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.

For example, when in VE, and wanting to create a category, the dialog could include the text of the section where the pointer was located when the dialog was invoked (scrollable on the left side of the dialog). That way, the user could selected text from the left side of the dialog and paste it into the right side. [I'm not arguing that this is optimal, just that it's another way to solve the underlying user problem.]

Given that a user wants to both interact with (or at least see) a page's content, and also interact with a somewhat complicated form/process (i.e. many controls/inputs, e.g. Rater, or in VE adding/editing a template with many parameters), what alternatives are there?

  • Unmovable dialog: Forces the user to swicth back-and-forth to another tab/window; or exit the dialog, find what they wanted to find, and go back in
  • Docking: Only works if your screen is big enough
  • Prepending to (or placing just above) the content area: Causes content to re-position, can't necessarily see both things at once (if scrolling is required), not really suitable if the form/process applies to only one section of the page
  • Appending to (or placing just below) the content area: Similar to prepending, but instead content re-positioning existing content, the form/process won't initially be visible on longer pages, unless you force the page to scroll there

I don't think those alternatives are actually better than letting the user move the dialog out of the way.

@John_Broughton, the StackExchange link makes me wonder whether we should be thinking of these as modal dialogs (something intended to interrupt the primary workflow [which is probably "typing text into the body of an article"] and requiring some action before you can get back to the primary workflow). Maybe editors would find it better to have a https://en.wikipedia.org/wiki/Palette_window instead.

I haven't thought this through, but, for example, to add a category to Wikipedia page, one could (1) select some text, and (2) tell VE that you want that text to be a category. The process would be similar to linking, where one selects text and then clicks on the link icon.

The linking process works really well in VE because the link icon is one click away from the text being edited, while categories are a menu choice, so two clicks away. But I doubt that anyone would complain about the extra click if setting up a category was almost as easy a process as creating a link.

Still, if one wants to dream about an even easier interface, it would be this:

(a) select some text
(b) a palette window automatically appears (relatively small, perhaps, since the editor might be selecting text to copy, move, or delete)
(c) click on an icon in the palette window to select a relevant action from the palette window (which might be expanded with a click, maybe showing the selected text in an attached window). The relevant options could include create a link, create a category, format the text as a heading, format a paragraph (block quote), format some text within a paragraph (bold, italic, etc)

In other words, in VE, when you select some text, VE would automatically say "Okay, here are your options for that text." [I have no idea how difficult this would be to program.]

@John_Broughton that seems to be assuming that the category name will appear as text somewhere in the article, but that will not always be the case. For example List of pear cultivars is in Category:Lists of foods. The words "Lists" and "foods" appear nowhere on the page other than the category names, even "food" appears only in the link to a portal and in the title of one reference and neither are in close proximity to any instance of the word "list". I imagine this will be even worse in languages where plurals are formed differently than in English.

Your idea also doesn't seem to relate to dialogs where information is being input from multiple different places in the article.

Back in May 2017 I commented:

I wouldn't object to dockable diaglogs appearing like that at the bottom of the screen as an option, but simply being able to move a reasonably sized box around the screen to a convenient point for the task at hand would be vastly superior imo.

@Spinningspark replied

Yes, that exactly sums up the issues. A moveable window is the best solution. The issue is being clouded with these alternative solutions and we have ended up with no solution at all.

We don't seem to have moved on at all in the last 2½ years.

I'm now totally unfamiliar with VE because I abandoned it years ago because I found it unusable. I simply wanted to be able to move the category input box away from being on top of the info I needed to categorise, which might have been a county name for a locality, or a footballer's birth decade and field position, etc. It seems, to a naive editor, a simple request.
Sent from Yahoo Mail on Android

Regarding "Your idea also doesn't seem to relate to dialogs where information is being input from multiple different places in the article", I'm not proposing this for all situations. In fact, I'm primarily interested in getting some action on the problem of more easily adding categories to articles.

And yes, it's true that some categories won't be have related text in the article. For that, one option is to leave the current menu-driven process as is (there isn't anything wrong with having two ways to do the same thing). Another option, of course, is for the user to select some (irrelevant) text, then when the dialog box occurs, change that text to whatever he/she wants as a category. (The selected text wouldn't be locked in any way, just as text selected to create a link can be changed by the user, in the dialog box.)

Again, my larger points are (a) if a moveable dialog box is either difficult to implement or undesirable from a UI/UX viewpoint, then (b) let's find specific solutions to specific user problems that don't require that approach.

(b) let's find specific solutions to specific user problems that don't require that approach.

Sure, but shouldn't they be discussed in more specific tasks? This task is for OOUI in general, which is used for more than just VisualEditor.

Evad37 renamed this task from OOjs UI: Dialogs should be repositionable/draggable to OOUI: Dialogs should be repositionable/draggable.Nov 18 2019, 2:18 AM
Evad37 updated the task description. (Show Details)
Aklapper changed the task status from Stalled to Open.Nov 1 2020, 8:42 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for six years for unclear reasons.

(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)