Opened 4 months ago
Closed 3 months ago
#18975 closed bug (fixed)
[Tracker] Incorrectly disables "New..." submenu for read-write dirs on some cases.
Reported by: | bipolar | Owned by: | jscipione |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | Applications/Tracker | Version: | R1/beta4 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
This is on hrev57936 64 bits (Tracker set to single navigation mode, if that matters).
Steps to reproduce:
- Open a Tracker window to ~/config/ (say, via drill-down menus):
The "New..." sub-menu is correctly disabled.
- Enter "non-packaged" in the same window via double click:
The "New..." sub-menu is *incorrectly* still disabled.
On the other hand....
- Directly opening a Tracker window into
~/config/non-packaged/
:
The "New..." submenu is correctly enabled.
---
Similar thing happens with /boot/system/
and /boot/system/settings/
, for example.
Change History (11)
comment:1 by , 4 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:2 by , 4 months ago
comment:3 by , 4 months ago
I'm going to try to split the relevant change out I'm pretty sure I've identified where the bug is happening. I'd like this bug fixed sooner and I'm not sure if Shortcuts refactor going to make it in before R1B5.
comment:4 by , 3 months ago
Split out fix in https://review.haiku-os.org/c/haiku/+/8002 for quicker inclusion.
comment:5 by , 3 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
Fixed in hrev57955.
comment:6 by , 3 months ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
comment:7 by , 3 months ago
I tested on hrev57966, 64-bit nighty build and the feature worked as expected with New menu disabled on read-only, and enabled on read-write folders. Single window nav turned on or off, reproducing the steps of this ticket and other folders as well.
Can you give me a more specific set of steps to make the show the wrong enabled status for New menu? I suspect this is indeed fix there is something else going on.
follow-up: 9 comment:8 by , 3 months ago
I see the problem now, I was looking at the File menu New and you’re looking at context click menu. I’ll need to update on window context instead of pose context.
comment:9 by , 3 months ago
Replying to jscipione:
[...] you’re looking at context click menu.
Yes. I should have been more explicit. Sorry!
comment:10 by , 3 months ago
It was a silly mistake on my part, I should have thought of that earlier. You were right-clicking I was looking in the File menu, so that's how both we were seeing different things.
The following PS should fix the issue on right-click as well:
comment:11 by , 3 months ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Fixed again in hrev57974.
This is fixed by my shortcuts refactor: https://review.haiku-os.org/c/haiku/+/7197/36 specifically ContainerWindow.cpp line 1509 where it says:
The bug is caused by not repopulating menus when you switch volumes, which you are due to packagefs shenanigans when you switch from ~/config to ~/config/non-packaged as well as from /boot/system/ to /boot/system/settings/. This was always a bug but it was hidden before I started disabling the menu items the "New folder" item as in R1B4 the menu item was always enabled even when it wouldn't actually work.