[Bug]: When closing a file the check for unsaved content always happens on the currently displayed file

[AJenbo]

What happened?

Since the last release CodeLite has started prompting to save the current file when closing other files.

Even worse, if you try to close another file that has not been saved but the current file has been saved it will close the other file and loose the unsaved changes.

Version

Self compiled

Operating system

Linux

Steps to reproduce

1: Open two files
2: Edit the current file
3: Middle click the other file
4: See the confirmation dialog.

1: Open two files
2: Edit the first file
3: Switch to the second file
3: Middle click the first file
4: See you unsaved changes get lost

Relevant log output

In previous releases it would correctly close the other file with out prompting, I would expect it to work the same after the UI refactoring.

[UffeJakobsen]

This seems related to (closed) issue #3367

[AJenbo]

This also affects the context menu, it will always act on the current tab rather then the tab you right clicked on (for example copy file name).

[yunkot]

I can also reproduce both these issues. Now it seems that right-clicking on tabs is not working as the actions always use the current tab, regardless on which tab you right-clicked.

[yunkot]

In addition that what's been said, it is also impossible to close any tab other than currently visible one. I like the fact that only currently visible tab has "x" to close, as long as other tabs can be closed using right-click then choosing "close"; however, because of this bug, right-click context menu always refers to currently visible tab regardless of what tab is actually right-clicked.

After having this issue for a while, I find it quite debilitating to the workflow. I'm offering a bounty of $50 for a fix.

[eranif]

In addition that what's been said, it is also impossible to close any tab other than currently visible one. I like the fact that only currently visible tab has "x" to close, as long as other tabs can be closed using right-click then choosing "close"; however, because of this bug, right-click context menu always refers to currently visible tab regardless of what tab is actually right-clicked.

After having this issue for a while, I find it quite debilitating to the workflow. I'm offering a bounty of $50 for a fix.

I am not sure what you mean. Did you try closing tab using the mouse middle button (clicking it) - this works for any tab, regardless if it is the active one or not

[UffeJakobsen]

I am not sure what you mean. Did you try closing tab using the mouse middle button (clicking it) - this works for any tab, regardless if it is the active one or not

Right click - on another tab than the selected/focused one - will show a context menu. Selecting "Close" in that context menu will close the wrong tab. The selected/focused tab will close - not the one that was right clicked...

That is at least the issue that I'm seeing...

[yunkot]

@UffeJakobsen: yes, this is exactly the issue I'm talking about and it affects all context menu actions, not just closing.

@eranif: middle-click does close the correct tab, but that implies starting to use mouse middle-click, which I find difficult because of my hand anatomy (I wonder how many people are actually capable and use mouse wheel for clicking?) But, this is unrelated to the issue described here.

[AJenbo]

mouse wheel for clicking?

I do, even for quoting you here I did. Considering how many shortcuts utilize it (open new window, close tab, copy-paste) I would say it's pretty common for people to middle click.

[eranif]

@yunkot I am so used to mouse middle click, that I don't use other alternatives for closing a tab (usually, I hide the 'x' button on the tabs to have more space). But I understand that not everyone is working the way I do...

[yunkot]

I do, even for quoting you here I did. Considering how many shortcuts utilize it (open new window, close tab, copy-paste) I would say it's pretty common for people to middle click.

The only application of mouse middle-click that I am aware of (at least until now) is for scrolling in some CAD applications, where other buttons are used for other functions. But it really depends on the mouse and hand anatomy. I'm using 3dconnexion CAD mouse, which actually has 2 middle buttons: one normal and another of the wheel, and both are configured for different functions. But I find it physically uncomfortable to use wheel-type button for middle-click. I've never used it for work, nor I have seen any of my colleagues or clients use it; in fact, many are unaware that the wheel can also be pressed to simulate middle-click.

However, I think this is off-topic, as the bug is related to the context menu, which has several other functions other than closing the tab, such as making the tab read only, copying file name, "compare with", etc. Whether or not the tab can be closed using other means or shortcuts is a good thing, but irrelevant to how this bug affects the workflow.

Again, the fact that there is only one "x" for the currently visible tab is a good thing, it's just the context menu that behaves not how you would expect it to.

[UffeJakobsen]

I'm currently using Logitech mouse (I own several versions/generations) I really like them - but they all have the same problem - middle button is achieved through a (hard) press on the scroll wheel. That is (for me) almost impossible to do without also scrolling a bit during the attempt to perform a middle click - leading to various side effects (depending on the current application). In the end all this leads to one thing - I'm not using middle click...

[AJenbo]

I use a Logitech MX 705, no issue there.

[UffeJakobsen]

I use a Logitech MX 705, no issue there.

Logitech M500S here - looks like yours - just with with usb "wire"... IMHO middle-click it totally unusable - you need to press too hard on the wheel - which will quite ofent also trigger a wheel direction "event" - and a double middle-click is totally impossible... :-/

[eranif]

@UffeJakobsen you should get yourself a "MX Master 3s for Mac" - you will thanks me later 😄

[eranif]

There are multiple issues mentioned here:

• Context menu on tab label is affecting the active tab
• (Windows / macOS): right clicking on a non active tab made it active before showing the context menu
• Losing unsaved changes

To mitigate this issue:

• Linux is no longer using wxAuiNotebook, instead it uses the same Notebook control used on macOS & Windows
• With this commit context menu is now working on the tab being hovered and not the active tab
• In addition, x button is now shown on all tab (same as Windows & macOS) and is clickable on non active tabs without making it active first

@AJenbo @yunkot - please give it a try

Tested on Windows & Linux Ubuntu 22.04

[AJenbo]

Looks to be solved (24.04). If there are remaining issues which have been mentioned in the comments of this issue then please open a new issue for them so that can be tracked individually.

[yunkot]

I haven't had much time to test this well, but from a quick check, all seem to be working. Many thanks! (P.S. Sent bounty as donation)