Question regarding the `$link` widget when its `draggable` attribute is set to `no`

Good day,
I am trying to disable link drag-ability through the draggable attribute of the $link widget, and doesn’t seem to behave as I expected it.

I would expect the widget’s draggable attribute when set to no to be rendered as a draggable="false" attribute to the rendered HTML <a tag, but that does not happen.

The link remains draggable as per this screen capture:

If however I force the "draggable=“false” attribute in the HTML tag using the browser’s developer tools, I get the desired behaviour (the link is not draggable):

The other preview modes (available via the Internals plugin) suggest the widget attribute is parsed correctly:


My work-around has been to modify:$:/core/modules/widgets/link.js

by adding the else statement below, but I am not clear on unintended consequences.

...
	// Make the link draggable if required
	if(this.draggable === "yes") {
		$tw.utils.makeDraggable({
			domNode: domNode,
			dragTiddlerFn: function() {return self.to;},
			widget: this
		});
	} else 
		domNode.setAttribute("draggable","false");
	}
...

Any idea?

Create a tiddler (e.g. “NoLinkDrag”), tagged with $:/tags/Stylesheet, containing:

.nodrag a { user-drag:none; -webkit-user-drag:none; }

Then, in your content, you can write:

@@.nodrag <$link to="HelloThere"/>@@

This method works for any link syntax (e.g.,[[sometiddler]] or automatic CamelCase links such as HelloThere) and can be used to wrap an entire section of content to disable dragging for all links in that content.

enjoy,
-e

Thanks @EricShulman; probably workable, though in my plugin, the attribute would be conditionally set, so slightly simpler for me to use as e.g. <$link ... draggable={{{ [[conditionalfiltergoeshere]] }}}>.

Do you happen to know why it is not carried through by the widget into a draggable="false" attribute in the HTML <a ...> tag?

In fact, it almost feels as this attribute doesn’t have any effect in the <$link widget…

The $link widget does process the draggable="no" widget attribute to prevent TWCore handling of drag-and-drop, but the browser itself is still allowing the underlying <a> HTML element to be dragged anyway. You can see this by comparing the tooltip that is displayed when dragging.

If you write

<$link to="HelloThere"/>

then the TWCore processes the drag and the tooltip is just the link text.

However, if you write

<$link to="HelloThere draggable="no"/>

then the TWCore drag handling is bypassed but the browser drag handling is setting the tooltip to show both the link text AND the underlying URL (at least, this is what Chrome does).

Thus, this would seem to be a legitimate bug in the TWCore’s $:/core/modules/widgets/link.js code, which could be fixed by applying the solution that you’ve already identified. I suggest you open a GitHub issue and submit a pull request for this code change.

In the mean time, a suitable workaround is for your plugin to define a stylesheet shadow tiddler containing

.nodrag { user-drag:none; -webkit-user-drag:none; }

and then you can use

<$link ... draggable="no" class={{{ [[conditionalfiltergoeshere]then[nodrag]] }}}>.

in your plugin to disable BOTH the TWCore drag handling and the underlying browser drag handling.

-e

submitted my very first PR (on any project) IMPROVE HANDLING OF $LINK WIDGET'S DRAGGABLE="NO" by bepuzzled · Pull Request #9262 · TiddlyWiki/TiddlyWiki5 · GitHub. Please afford it extra reviews.

(out of curiosity, seems other PRs largely don’t have a capitalized title. Should I have not ? ref: https://tiddlywiki.com/#Contributing)

2 Likes

Congratulations on submitting your first PR!

In this context, “capitalized” means that the first letter of the first word should be upper case, but the rest of the sentence should be lower case (except for proper nouns, of course). I’ve fixed your PR title.

Also, with a few exceptions here and there, we generally don’t include comments in the TWCore code. I expect that someone will tweak your PR to remove those comments before it is incorporated into the codebase.

-e

1 Like

Fantastic, thanks a million for the tips and for fixing the PR…
(I find my mistake related to capitalization actually pretty funny…
created a documentation PR to help others avoid making the same mistake: Improved guidelines for PR title capitalization by bepuzzled · Pull Request #9263 · TiddlyWiki/TiddlyWiki5 · GitHub)

1 Like