UI issue - dragging folders to reorder - virtually impossible without the dragged folder ending up in subfolder
- Dominant language
- TypeScript
- Stars
- 40k
- Forks
- 2.4k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 61
Description
### Expected Behavior
when dragging a folder to a different spot in the order in relation to its siblings, that dragged folder should not end up in a subfolder.
There should a clear visual indicator which level that folder will be dropped at.
### Actual Behavior
a dragged folder ends up as a new subfolder in the sibling folder. 99.99% of the attempts. Once in a while it works as expected but it is not visually clear why (no indicators) and not predictable.
### Reproduction Steps
Version: Insomnia 8.4.2
Build date: 11/15/2023
OS: Darwin x64 21.6.0
Electron: 27.0.3
Node: 18.17.1
Node ABI: 118
V8: 11.8.172.16-electron.0
Architecture: x64
- create a folder
- create multiple subfolders
- select and drag such a subfolder to a different location in relation to its siblings
- that folder will now become a folder within its sibling where it was dragged under
### Is there an existing issue for this?
- [X] I have searched the [issue tracker](https://www.github.com/Kong/insomnia/issues) for this problem.
### Additional Information
I noticed there was a similar issue that was closed in August. That one mentioned both folders and requests. My issue is only with folders. Requests seem to work fine, although there too there is not a clear visual indicator at what level the request will be put.
### Insomnia Version
8.4.2
### What operating system are you using?
macOS
### Operating System Version
macOS 12.7.1
### Installation method
download from insomnia
### Last Known Working Insomnia version
_No response_
Contributor guide
Research direction
Start by reproducing the folder-reordering behavior using the listed steps in Insomnia 8.4.2 on macOS, focusing on the drag-and-drop UI for sibling folders. Trace the folder drag/drop entry point and identify where the target nesting level is determined; done means sibling reordering is predictable and the destination level has a clear visual indicator.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- electron, typescript
- Domain
- desktop, frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100