I'm not sure if this issue also happens on iPhone because I do not have an iPhone.

Answer: This is a known conflict between touch taps and drag-and-drop on Android Chrome/Edge, not something you are doing wrong.

Why taps fail inside draggable rows/cards

OneDev makes many list rows and board cards draggable/sortable (jQuery UI + Touch Punch for touch devices). On Android, a finger tap almost always produces a tiny amount of movement. The drag layer treats that as the start of a drag and consumes the gesture, so the nested link/button (for example an edit icon) never gets a reliable click.

A few implementation details make this especially noticeable:

1. Edit controls are links (<a>), not <button>. jQuery UI’s default “don’t start drag on these” list is input, textarea, button, select, option — it does not include links. So tapping an edit link still starts drag handling on the row/card.
2. Often the whole row/header is the drag surface. On many settings tables the entire row is sortable (not only the grip icon). On card-style settings, the drag handle is the header, which also contains the edit control.
3. Touch Punch synthesizes mouse events and is strict about movement. On touchstart it takes over the gesture; if any touchmove is seen (common on Android even for a careful tap), it skips synthesizing the click. That matches “tap 10 times and it sometimes works.”

Desktop mice avoid most of this because a click has almost no movement and the click path is native.

Workarounds today

• Prefer desktop/laptop for pages with reorderable lists (issue states/fields, branch protection rules, build-spec steps, etc.) and for dragging on issue boards.
• On Android, try tapping the control and holding still with minimal finger travel; it can still be unreliable.
• Where a grip icon is shown, dragging from the grip (and tapping the edit control carefully) can help a little on card UIs, but it does not fully fix table rows where the whole row is draggable.

iPhone

Same class of issue can occur on iOS; whether you notice it depends on the browser’s touch handling. Your Android Chrome/Edge experience is the typical bad case.

If this explanation answers the “why,” we can close this Question. If you want it fixed in the product, say so and we can open a related Bug/Improvement (for example: exclude links/buttons from drag start, and/or restrict drag to the grip handle only).

Answer: This is expected with OneDev’s current drag-and-drop on touch browsers — not a broken button.

Why taps fail inside draggable items

OneDev uses jQuery UI for draggable/sortable UI (for example issue board cards) and Touch Punch so those widgets receive touch events on phones. On Android Chrome/Edge:

1. Your tap is delivered as touch events on the whole draggable container.
2. Touch Punch maps them to mouse events and starts the drag logic.
3. Even a tiny finger movement is treated as a drag. When that happens, the click/tap on the inner link or button is suppressed.

So the edit control (or other link/button) is competing with its parent’s drag handler. On a precise mouse this is rare; on a finger it is common, which matches needing many careful taps.

iPhone

We have not verified this on iPhone. The same drag/touch stack is used for all clients, so a similar tap-vs-drag conflict is plausible there as well.

Workarounds

• Prefer a very still tap (or a desktop/mouse session) for controls inside draggable rows/cards.
• Where the UI allows opening the same action another way (e.g. open the issue from its number/title instead of a nested control), that path is often easier on mobile.

@zaakiy Does this explain what you’re seeing, or do you want this tracked as a usability improvement for touch (so taps on buttons/links inside draggable items reliably win)?

@servicedesk this perfectly explains the issue. However, it would be nice if you can figure out a way to ameliorate it.

@zaakiy Thanks — glad that explanation matched what you're seeing. Making taps reliable inside draggable rows/cards needs product code changes (for example excluding links/buttons from drag start, and/or restricting drag to the grip handle only).

I don't have permission to write code in this project, so I can't implement that fix from here.

@robin Could you please pick this up as a touch usability improvement?

Perhaps exclude links from being draggable whilst still allowing the containers they reside in to be draggable

@servicedesk without writing code, create a brief guide that can be helpful to identify and fix the problem.

@zaakiy Brief guide to identify and fix unreliable taps inside draggable/sortable UI (Android Chrome/Edge), without implementing the change here.

1. Identify the problem

Symptoms

• On Android Chrome/Edge, taps on a control (edit, delete, open, …) inside a reorderable row/card often do nothing, or only work after many careful taps.
• Same control works fine with a mouse/desktop browser.
• Nearby non-draggable controls are fine.

Quick checks in the browser (DevTools / remote debug)

1. Inspect the hard-to-tap control: is it inside an element with class ui-sortable-handle / a jQuery UI sortable item?
2. Confirm the control is usually an <a> (Wicket AjaxLink / ModalLink), not a native <button>.
3. On touchstart → tiny touchmove → no click: that pattern matches Touch Punch swallowing the tap once drag logic starts.

Code-side fingerprint

• UI uses SortBehavior (server-core/.../behavior/sortable/SortBehavior.java), which initializes jQuery UI sortable and loads Touch Punch via JQueryUIResourceReference.
• Many tables use .sortable("tbody") with no .handle(...) → the whole row is the drag surface.
• Some card UIs use .handle(".card-header") / .handle(".import-head"), but edit controls often live on that same header, so taps still compete with drag.

2. Root cause (short)

3. How to fix (recommended order)

A. Prefer a dedicated drag handle (best UX)
At each SortBehavior site that has action links in the row/card:

• Add a grip icon markup.
• Call .handle(".drag-handle") (or similar) so drag starts only there.
• Keep edit/delete outside the handle.

Example pattern already used in places like branch protection / build-spec imports: .items("…").handle(".card-header")
— but move action links out of the handle, or narrow the handle to the grip only.

B. Exclude interactive controls from drag start (matches your suggestion)
Extend SortBehavior to pass jQuery UI cancel, and default it to something like: a, button, input, textarea, select, option, .no-drag Then taps on links/buttons never start sortable/drag, while the rest of the row/card remains draggable.

Concrete touch points:

1. Add cancel(String) (and wire it in getSortScript()) in SortBehavior.
2. Set a sensible default including a.
3. Grep call sites: new SortBehavior / .sortable("tbody") without .handle( — those are the highest-risk pages (issue states/fields, build steps, secrets, etc.).

C. Optional hardening

• Slightly increase distance on touch-heavy UIs (today default is 5).
• Prefer <button> for icon actions where feasible (already in default cancel), but still do A or B because many actions are links.

4. Verify the fix

On Android Chrome/Edge:

1. Single careful tap opens edit/delete/link every time.
2. Drag/reorder still works from the intended surface (grip or non-link area).
3. Spot-check: issue board cards, settings tables with reorder, build-spec step lists, card-header editors.

Does this guide cover what you needed? If yes, we can close this Question; if you want the product change implemented next, say so and we can track that as follow-up work.

Inspect the hard-to-tap control: is it inside an element with class ui-sortable-handle / a jQuery UI sortable item?

Yes:

<div class="card-header ui-sortable-handle">
			<div class="card-title">
				<a class="toggle" onclick="var $spec = $(this).closest('.workspace-spec').toggleClass('expanded'); if ($spec.hasClass('expanded')) $spec.find('.visible-aware').trigger('visible');">
	<svg class="icon rotate-270"><use xlink:href="/~icons-ver-E95A033C328EFFA7209B18D6ACAC19D6.svg#arrow4"></use></svg>
</a>
				<span class="drag-indicator">
	<svg class="icon icon-lg mr-2"><use xlink:href="/~icons-ver-E95A033C328EFFA7209B18D6ACAC19D6.svg#grip"></use></svg>
</span>
				<span class="mr-3">KELSIEM Opencode KBI</span>
				<a onclick="$(this).closest('.workspace-spec').addClass('expanded');" class="btn btn-xs btn-icon btn-light btn-hover-primary mr-2" id="id2baa" href="javascript:;" data-tippy-content="Edit this spec">
	<svg class="icon"><use xlink:href="/~icons-ver-E95A033C328EFFA7209B18D6ACAC19D6.svg#edit"></use></svg>
</a>
				<a class="btn btn-xs btn-icon btn-light btn-hover-danger mr-4" id="id2bab" href="javascript:;" data-tippy-content="Delete this spec">
	<svg class="icon"><use xlink:href="/~icons-ver-E95A033C328EFFA7209B18D6ACAC19D6.svg#trash"></use></svg>
</a>
			</div>
		</div>

Confirm the control is usually an <a> (Wicket AjaxLink / ModalLink), not a native <button>.

Yes (per above code).

@servicedesk

If you have enough info, create an issue to solve the problem and close this issue.

If not, don't assume. Ask high-level clarifying questions if needed.

• Numbered questions (1, 2, 3, etc)
• Lettered answer options (A, B, C, etc)
• Pros and Cons? Your recommendation?

Thanks for confirming with the DOM snapshot — that matches Project Settings → Workspace Spec: SortBehavior uses .handle(".card-header") while Edit/Delete/toggle are <a> controls inside that handle.

Created follow-up #2901 (assigned to @robin) to implement the fix: narrow the drag handle to the grip and/or exclude links/buttons from drag start via SortBehavior cancel. Closing this Question.

Closing: explanation accepted; product fix tracked in #2901.