[IDEA] It is proposted to add a "listactions" parameter to the droppable widget which acts different to "actions"

[pmario]

There is a problem if a tag-pill with hundreds of titles is dropped onto a user defined droppable-widget which in turn uses the action-confirm-widget. The confirm dialogue will pop up hundreds of times, with no possibility to stop it.

Proposal

It is proposed to add a new parameter eg: listactions to the droppable-widget. The connected action should get a variable eg: actionTiddlerList which contains a TW TitleList

• The existing actions parameter will still execute 1 action per tiddler
• The new listactions parameter will only execute 1 action for the whole TitleList

This makes it possible to check the number of titles, that will be dropped with a filter eg: [<actionTiddlerList>split[ ]count[]]. If the counter is too high, the user can decide how to handle the long list.

• The idea contains a new "action variable" actionTiddlerList
• The existing actionTiddler variable has 2 different behaviours.
  • I think we should change that in a different PR.

@Jermolene -- What do you think?

PS: Related post at Talk: https://talk.tiddlywiki.org/t/drag-and-drop-tag-pills-is-dangerous-tag-pills-can-have-big-drag-payloads/9768
PPS: The code change is simple. 9 lines of new code.

[Jermolene]

Hi @pmario the use of the droppable widget in the OP does seem to me to be somewhat incidental; I see the problem as being more about the way that a sequence of <$action-confirm> widgets will block the user from doing anything. Indeed, one can duplicate the problem without using the droppable widget.

Somebody suggested an option to cancel all future confirmation dialogues, but of course that is not something that browsers support. In any case, in the future we may have to remove <$action-confirm> if browsers go ahead with their threat to remove the underlying confim() method.

So, I'm not sure there is much future for <$action-confirm>. We would be best to be trying to come up with alternative mechanisms for confirmation. In particular, the problem is that <$action-confirm> blocks the browser JS and UI threads, which profoundly limits what we can do with them.

Lacking a good solution to the problems with the <$action-confirm> widget does take us back to your proposal for improving the <$droppable> widget. It's a neat solution, but from a user perspective it seems clumsy: it would mean that there are two ways to trap incoming drop events, with users needing to figure out which one is the right way. We'd still have the situation where naively written drop handlers would run into problems when dragging tag pills containing a large number of tiddlers.

On balance, I'd be inclined to keep this problem under consideration until we've got a better fix.

[pmario]

On balance, I'd be inclined to keep this problem under consideration until we've got a better fix.

The draggable widget has 2 different actions that work with a TitleList. For consistency reasons the droppable widget should have the same mechanism.

For backwards compatibility reasons we cannot remove the existing action, which can cause the "confirm" problem by accident.

With the proposed mechanism we could make the behaviour for draggable and droppable more consistent.
We could deprecate the existing actions parameter.

---

I did create a concept to "chain" the cancel mechanism, but due to the nature of the confirm dialogue it would be super clunky and I did create this proposal instead.

[pmario]

We could also create a new droppable-widget, with only 1 actions parameter but with the proposed actionTiddlerList handling, which activates the action only once.

[AnthonyMuscio]

I see the problem as being more about the way that a sequence of <$action-confirm> widgets will block the user from doing anything. Indeed, one can duplicate the problem without using the droppable widget.

Background: I have a modified tag bar that allows titles to be dropped on it to add the title as a tag. It is very useful and I was reviewing it before publishing it.

The action confirm widget was used by me to test if the title being dropped on the tags list was already a tag. The idea is to give a user the ability to proceed only if they are happy to make a new tag. Removing it is trivial, and in many ways unrelated to the problem. I have a wiki where a common action is to add a tag, one of a few, that already tags hundred other tiddlers. If I accidently drag the tag pill rather than a link title, I instead add the hundreds of tiddlers to the targets tags field.

Dragging a tag pill is useful, and somewhat "instinctive" but in this case it is a risk, in part because I cant intervein in the droppable widget to stop or even prompt before proceeding to apply all titles. Only one title at a time.

If I could count the titles being dropped,

• I may just show a prompt "Apply 850 titles as tags OK/Cancel" if more than one, or more than 10 titles etc...
• Of course I could also mistakenly say OK and I have all the titles applied. Not too bad, but I wanted the prompt/confirm widget if its not already a tag - the problem returns, I cant cancel out once committed.

There needs to be a way to intercept the drop so an additional condition and branch can be added, according to the content of the drop, and as a result be able to cancel.

• Can I do this in the existing actions?

[AnthonyMuscio]

We could also create a new droppable-widget, with only 1 actions parameter but with the proposed actionTiddlerList handling, which activates the action only once.

Perhaps the droplist widget? for dropping zero or more titles.

With

• On drop actions
• On each title actions within conditionally.

Thanks for running with this @pmario

[pmario]

If I could count the titles being dropped,

• I may just show a prompt "Apply 850 titles as tags OK/Cancel" if more than one, or more than 10 titles etc...

With the current implementation that's not possible, since the widget already separates the list an activates 1 action per tiddler.
That's why I did create this proposal, which will allow us to activate the actions parameter or the listactions parameter. The listactions parameter will activate 1 action with the whole list.

There you can count the members of the list and split them yourself in the action code.

---

IMO a new widget is suboptimal since it would duplicate the whole code and the draggable widget already works with a list instead of single titles. So for consistency reasons it would also make sense.

[pmario]

@Jermolene wrote

So, I'm not sure there is much future for <$action-confirm>. We would be best to be trying to come up with alternative mechanisms for confirmation

IMO the action-confirm widget has nothing to do with the proposal. It only happened to be the cause to make the underlaying problem visible.

The problem is: At the moment the droppable widget does internally split the title-array into single tiddlers and it calls the actions macro for every tiddler. So even if there would be a modal, which implements the user interaction it would still be a problem.

IMO the only solution is, that the droppable widget gets a "TitleList" mode, where the user can decide what to do with a huge list.

The code change is simple and would be in line with the "draggable-widget".

@Jermolene - So what I do not understand is the hesitation against that change.

[bluepenguindeveloper]

The issue of too many confirms seems to be possible with anything that loops actions (and doesn't know what actions it's looping through), but as for droppable, I wonder if simply adding a "limit" attribute would be nice to have (regardless of what actions are performed). In general, it might be nice to be able to add a limit attribute to anything that could take an unknown number of items, regardless of actions or anything else involved. (Another example of this would be in the browse widget when multiple is enabled, to limit the number of files the user can upload.)