Conversation
09b957b to
233ee3b
Compare
|
The slash in the branch name stopped the build server from building this, pushed to Edit: Looks like Ashley pushed |
jacobgkau
left a comment
There was a problem hiding this comment.
I'm seeing a couple of problems with this on 233ee3b.
First, when the tab's dragged over the path bar or the folder contents, those things are highlighted as potential drop targets, but dropping there doesn't do anything.
Since it's so easy to hover over those areas while dragging such a short target, and because the folder view drop target's so large and distracting, it would be better if the drop target didn't show the preview outline if it's not actually a supported drop target for tabs (and even better if, while dragging a tab, going above or below the tab bar still just tracked the horizontal position on the tab bar).
2026-01-21.11-58-14.mp4
Also, I'm sometimes seeing the tab switch when I didn't click the other tab after dropping one tab onto where another used to be. (It makes sense this would happen if I drag a background tab, as it's simply bringing the foreground tab back into focus; but it's also sometimes switching me after dragging the foreground tab, so some logic there may not be working properly.)
011feb1 to
63da513
Compare
jacobgkau
left a comment
There was a problem hiding this comment.
On 63da513, it appears the drag is simply dropped (without doing anything) if the mouse goes vertically outside of the tab bar.
2026-01-22.12-29-10.mp4
Since the tab bar's so short, this makes the drag & drop feel very finnicky, since it's easy to accidentally move the mouse above or below the tab bar while dragging a tab horizontally.
For comparison, Dolphin keeps the tab grabbed regardless of how far above or below the mouse cursor gets (as long as the mouse button's still held down):
2026-01-22.12-34-23.mp4
Meanwhile, the 24.04 version of Nautilus allows some buffer space above and below the tab bar (which is also slightly taller than ours); when the cursor gets far enough away, it does stop dragging the tab, but that's because it starts dragging the window instead (as opposed to just releasing the grab like we currently are):
2026-01-22.12-35-42.mp4
In Firefox, there's similarly some buffer space above & below the tab bar before other actions are triggered, although it appears to be slightly less than what Nautilus provides. Importantly, though, Firefox also resumes the tab grab if you move the mouse cursor back into the tab bar, whereas we're currently losing the grab entirely:
2026-01-22.12-37-00.mp4
Not sure if @pop-os/ux has any input on how exactly it should work, but it seems like we should at least retain the grab if the mouse cursor re-enters the tab bar, rather than completely releasing the grab as soon as the cursor exits the tab bar.
jacobgkau
left a comment
There was a problem hiding this comment.
This is behaving well enough now to release as an initial implementation. You still need to drag the tab back into the tab bar to drop it, but you can now move the mouse outside of the tab bar while dragging and it won't lose the drag. Dragging a background tab now simply activates it after it's dropped, which makes sense and is more consistent with both web browsers and other file managers than the previous behavior of keeping it in the background after it's dropped.
Regression testing passed:
Checklist
Basic navigation
- Middle-click opens directory in a new tab (not focused).
- Open two scrollable tabs. Scroll one tab, then switch to the other tab; it should not have scrolled.
- Hover over the top item in the folder, then scroll down until it's out of view (while still hovered). On scrolling back up (with the mouse in a different position), the item should not have the hover highlight.
- Right-click an item in the sidebar. No visual change should occur with the rest of the items.
- Not a regression.
- Remove an item from the sidebar, then re-pin it.
File operations
- Right-click -> Create a new folder, then enter it.
- Right-click in the empty folder -> Create a new file.
- Navigate to the parent folder, create another new file, then drag it into the created folder.
- Files can be renamed.
- Files can be opened with non-default apps & browsing store for new apps works.
- Normal right-click shows
Move to trashoption. - Shift right-click, and right-click followed by Shift, both show
Permanently deleteoption.
Advanced navigation & view settings
- Image and video thumbnails generate & display in local folders.
- Gallery preview shows with Spacebar.
- Details pane shows with Ctrl+Spacebar.
- Zoom in/out and reset to default zoom work.
- Ctrl+1 and Ctrl+2 switch between list and icon view.
- Ctrl+H shows/hides hidden files.
- Directories can be sorted at top or inline.
- Settings -> Theme works.
- Settings -> Type to Search affects behavior as designed.
- Single-click to open setting takes effect.
- Sorting options work.
- Cutting, copying, and pasting files works.
- F5 reloads current directory.
- Left sidebar can be collapsed and expanded.
External filesystems
- Add a network drive (e.g. SFTP) and navigate into it.
- Plug in a USB drive; able to mount, browse, and eject.
Integrations
- Desktop icons display as expected
- Drag-and-drop into Firefox works
There was a problem hiding this comment.
When I went on to test pop-os/cosmic-edit#490, I noticed a problem that's also present here. Normally, the foreground tab's text is bold, and background tabs' text aren't bold. When I drag a tab, sometimes a background tab has its text become bold, and it sometimes remains that way until it's activated and re-activated. See below:
2026-01-26.13-41-53.mp4
It seems like when the background tab becomes bold and when it goes back to normal on its own (if ever) has to do with where the cursor moves. As you can see, in one of those instances, it looked like it went back to normal after the mouse cursor went over it and then back off of it again. (Other times, it seemed like more of a time delay, but I'm not sure what the actual cause is.)
In COSMIC Edit, it seems to do more with when something's clicked and less with the cursor position or time.
|
While I think that is an issue, it seems to me like this kind of bold tab title issue isn't really a regression. For example, I can recreate the issue in a different way if i hover over an inactive tab then press a modifier like control or shift, and after moving my mouse away, the text is still bold to indicated hover state. And actually, looking at the code, it was intended to be bold when hovered, even if inactive. I understand if we'd like to fix this issue before merging though, because tab drags seem to make the issue easier to encounter. |
|
I agree it's not a technical regression since it can be triggered already with modifier keys (I didn't think to try that before). But also, yes, draggable tabs more easily expose the issue. I wouldn't be opposed to moving forward with this anyway if there was a benefit to doing so (e.g. if we know we're not going to be able to fix the boldness issue for a while), but it would be ideal to take care of it at the same time if it's possible. Like I said, in COSMIC Edit, just hovering and un-hovering doesn't fix it-- instead, to un-bold the inactive tab, I either need to click something, press a modifier key, or type in a way that changes the active tab's label with the edit indicator. I'm assuming COSMIC Edit handles focus differently because of the nature of the app. |
bddb907 to
067a3f1
Compare
|
Ok, this should fix hover issues. |
|
When dragging a tab over another tab, the inactive tab's becoming highlighted even when the drag's active and dropping would not activate the inactive tab. That's not a critical issue. But do you know why the inactive tab becomes highlighted if the cursor enters from the sides, but not if it enters from the top or bottom? 2026-01-27.16-44-49.mp4 |
|
I'll check, because I remember noticing something off similar to what you described, but I thought it was fixed now. I can't seem to tell what the issue is from the video though. |
jacobgkau
left a comment
There was a problem hiding this comment.
The bolding problem I showed in #1535 (comment) is fixed. I'm not seeing any more problems now.
Regression testing passed:
Checklist
Basic navigation
- Middle-click opens directory in a new tab (not focused).
- Open two scrollable tabs. Scroll one tab, then switch to the other tab; it should not have scrolled.
- Hover over the top item in the folder, then scroll down until it's out of view (while still hovered). On scrolling back up (with the mouse in a different position), the item should not have the hover highlight.
- Right-click an item in the sidebar. No visual change should occur with the rest of the items.
- Not a regression.
- Remove an item from the sidebar, then re-pin it.
File operations
- Right-click -> Create a new folder, then enter it.
- Right-click in the empty folder -> Create a new file.
- Navigate to the parent folder, create another new file, then drag it into the created folder.
- Files can be renamed.
- Files can be opened with non-default apps & browsing store for new apps works.
- Normal right-click shows
Move to trashoption. - Shift right-click, and right-click followed by Shift, both show
Permanently deleteoption.
Advanced navigation & view settings
- Image and video thumbnails generate & display in local folders.
- Gallery preview shows with Spacebar.
- Details pane shows with Ctrl+Spacebar.
- Zoom in/out and reset to default zoom work.
- Ctrl+1 and Ctrl+2 switch between list and icon view.
- Ctrl+H shows/hides hidden files.
- Directories can be sorted at top or inline.
- Settings -> Theme works.
- Settings -> Type to Search affects behavior as designed.
- Single-click to open setting takes effect.
- Sorting options work.
- Cutting, copying, and pasting files works.
- F5 reloads current directory.
- Left sidebar can be collapsed and expanded.
External filesystems
- Add a network drive (e.g. SFTP) and navigate into it.
- Plug in a USB drive; able to mount, browse, and eject.
Integrations
- Desktop icons display as expected
- Drag-and-drop into Firefox works
No description provided.