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.

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.

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.

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?

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

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.

@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.

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.)

I would like this to be in 5.3.4 if possible. I have a solution where any title can be dropped on an alternative view template tag area, to tag the target with the dragged tiddler.

This is a fantastic way to place any tiddler into a TOC and in turn add items to the TOC. It will complement the improvements to the TOC rewrite

The only problem is if this is done with a tiddler tag pill, which is a natural instinct, tagging many tiddlers, the whole thing becomes unmanageable and may result in lost changes.

• With this feature in the "list actions" we can test the number of titles in the payload and choose not to process all of them.

@AnthonyMuscio -- See: #8256

It's a bit late to the party. I did the coding and the docs. So you have to convince Jeremy to include it into v5.3.4

We've passed the code freeze for v5.3.4 so this will have to wait for a subsequent release.