New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[IDEA] Add mobile support for draggable tiddlers #5102
Comments
Hi @cipharius the situation with drag and drop is a bit patchy across different platforms; for example, it does work on iPad since (I think) iOS 13, but it doesn't work on iPhones. What platforms are you interested in? |
I'm specifically interested in Android chrome browser support, so that I could use TiddlyWiki as PWA. |
Hi @cipharius this table suggests that recent Chrome for Android does support drag and drop: What version are you using? |
That's odd, attempting to drag items in draggable todo list example just scrolls the page, or when held too long, shows context menu. Searching online does not mention any caveats to take care of. I just tested drag and drop example from MDN and it works. I think the issue here is that instead of initiating the drag when holding down on an item, it instead opens context menu for the link. The MDN drag event example: https://developer.mozilla.org/en-US/docs/Web/API/Document/dragend_event |
I can confirm that the MDN example works for me but drag and drop in TW does not. Chrome for Android 86 |
I suspect the difference might be explained by the fact that most draggable items in TW are links whereas the MDN example uses DIVs. |
I have found a workaround for this problem, perhaps it can give an idea how to properly handle draggable tiddler lists. My setup is similar to the example draggable ToDo list except each item is wrapped in a div with attributes Then have this script snippet with <script>
document.addEventListener('dragstart', e => {
if (e.target && e.target.classList.contains("custom-draggable")) {
let tiddler = e.target.querySelector(".tc-tiddlylink");
e.dataTransfer.setData('text/plain', tiddler.innerText);
}
});
</script> Now it's possible to drag list items on android chrome, by longpressing on the space next to tiddler title. |
@cipharius thank you for that. It helps confirm that the issue is indeed the contextmenu being triggered on links instead of drag. Another workaround could be to wrap the links in a |
@saqimtiaz Thank you, I'm still finding my way around TiddlyWiki architecture. Using DraggableWidget I got this task template: <$draggable filter="[<currentTiddler>]">
<$checkbox tag="done"> <$link/> </$checkbox>
</$draggable> While this works on desktop, for some reason on mobile it adds extra |
@cipharius So the draggable widget payload is a title list rather than a tiddler title. In a title list any tiddler title with spaces is enclosed in double brackets. So the key here would be handling the title list (and brackets) in the actions that occur when the drag ends. Are you using a droppable widget? If you post the entire code for your draggable list we can workout a solution. Alternatively you could post a TiddlyWiki file with the relevant code as well. |
@cipharius it also occurs to me that the |
I tried changing tag of link widget and I still get the issue, where extra TaskTemplate:
WikiText for the list:
My intent is to group tasks by project and let the tasks have different order in each project. |
@cipharius apologies for the late reply. I needed to find the time to do some debugging. You are correct. The Any thoughts on this @Jermolene ? I assume we always wrap tiddler titles with spaces, irrespective of whether they already are wrapped in brackets, to support titles like: So interestingly, on Android Chrome, the On Desktop, the same One kludgy workaround is to use the 5.1.23 pre-release version and customize the
With this change and no extra JavaScript needed you can use the following task template:
|
Very strange. It's true that Is it just that the droppable widget is expecting a title, while the draggable widget is providing a title list?
That makes it sound as if the problem is some inconsistency with the |
@Jermolene that is the symptom rather than the root problem as it is only in Chrome on Android that the draggable widget provides a title list, on desktop it provides a title. I believe this is due to the different
So I've confirmed that utils.makeDraggable is setting up all the different So the only type available to import to I can try to do some more debugging later today. I welcome any thoughts or suggestions. |
@Jermolene I'm wondering if this might be a bug with Chrome on Android and how it handles |
Thanks @saqimtiaz this is a tricky area. I recall that the combination (and ordering) of the types that are set and retrieved was very fiddly when I first set things up. One point to remember is that we need to be able to drag draggable things into text areas and get a title list (including textareas outside TiddlyWiki), so we can't do things like overload the text type with a JSON representation. |
Agreed. If it is a browser bug and we do decide to ameliorate it, I would favour trying to make the wiki text macros more flexible regarding their input variables. Ultimately it may be that we should not do more than just document the idiosyncrasy if it is a browser inconsistency. |
@Jermolene I can confirm that is a browser issue and not a TiddlyWiki bug. I modified the MDN drag example to set two I do not think there is much we should do to try and work around this. My only thought is whether in The impact would be minimal for non-mobile Chrome use cases but it would resolve this problem and make drag usable on Android. |
Thanks @saqimtiaz
Could it be that Chrome on Android has an accept list of content types that it will accept? I recall that's why we put some of the setData calls behind an IE conditional.
That sounds like it might break things elsewhere? If we don't call stringifyList then the other end can't distinguish between dragging "A B C" and "[[A B C]]"?
It would certainly be great to get it working. |
Not that they have documented anywhere. However there are many bug reports going years back of the same problem in Chrome for Desktop, where only the type
Good point. I'll do some testing post 5.1.23 and see if there is a way we can mitigate this problem. It is good to know though that the problem isn't in our handling of the event. |
Thanks @saqimtiaz much appreciated (I've always found working on drag and drop rather dispiriting because of the rampant browser incompatibility). |
PS: I was thinking mostly in terms of the I empathize with you on the frustrations of browser incompatibility in this area, which is why I want to see if there is a relatively easy workaround, but beyond that I do not think we should extend ourselves over this. |
This problem is related to that PR "review but don't merge: fix dropzone closure variable problem" #6622 |
Is your feature request related to a problem? Please describe.
Draggable lists work well on desktop browsers, but are not supported on mobile web browsers.
Describe the solution you'd like
Additionally to
dragstart
anddragend
events, listen fortouchstart
,touchmove
andtouchend
.$:/core/modules/utils/dom/dragndrop.js
can be refactored so that same logic can be reused for both touch based and drag based events.Describe alternatives you've considered
N/A
Additional context
N/A
The text was updated successfully, but these errors were encountered: