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 waddlesplash, 4 months ago

Owner: changed from nobody to jscipione
Status: newassigned

comment:2 by jscipione, 4 months ago

This is fixed by my shortcuts refactor: https://review.haiku-os.org/c/haiku/+/7197/36 specifically ContainerWindow.cpp line 1509 where it says:

if (... || wasVolume != IsVolume())
    RepopulateMenus();

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.

comment:3 by jscipione, 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 jscipione, 3 months ago

Split out fix in https://review.haiku-os.org/c/haiku/+/8002 for quicker inclusion.

comment:5 by waddlesplash, 3 months ago

Milestone: UnscheduledR1/beta5
Resolution: fixed
Status: assignedclosed

Fixed in hrev57955.

Last edited 3 months ago by jscipione (previous) (diff)

comment:6 by bipolar, 3 months ago

Resolution: fixed
Status: closedreopened

Sadly, the fix from hrev57954 doesn't seems to be working too well, as it now leaves the "New" submenu enabled all the time, even on read-only folders...

Easy to reproduce by opening any read-only folder.

(tested on hrev57966, 64 bits).

Version 0, edited 3 months ago by bipolar (next)

comment:7 by jscipione, 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.

comment:8 by jscipione, 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.

in reply to:  8 comment:9 by bipolar, 3 months ago

Replying to jscipione:

[...] you’re looking at context click menu.

Yes. I should have been more explicit. Sorry!

comment:10 by jscipione, 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:

https://review.haiku-os.org/c/haiku/+/8039

comment:11 by waddlesplash, 3 months ago

Resolution: fixed
Status: reopenedclosed

Fixed again in hrev57974.

Note: See TracTickets for help on using tickets.