Created attachment 193217 [details] Sample spreadsheet 1. In a spreadsheet, Insert a comment in a cell 2. Right-click the cell, enable "Show comment" so that it remains shown at all times, not only on hover. 3. Deselect the cell 4. Try to right-click anywhere on the shown comment Result: it selects the cell underneath the comment, instead of selecting the comment for right-click operations. See attached sample, and attached demonstration video. ----- Tested with: Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded This was tested primarily under Wayland, but I believe this was happening with Xorg too, in every previous LibreOffice release.
Created attachment 193218 [details] Demonstration video
Imagine that you actually want to select one of the cells that are covered by the presence of the comment. With the current behavior, you can select any cell, including those "behind" the comment. That is, either by right-click, or by keyboard. So, you would probably ask... How would you select the comment instead? The answer is with the normal mouse button (i.e left-click). And that is how we end up with your question... How to right-click on the comment? The answer is: 1. left-click on the comment, so it is shown as "selected"; and then, 2. right-click on the same comment. The context menu for the select comment will show up. Other tools might use other methods, but ATM this is how it works for all LO modules. I am setting this report as NAB. Feel free to add relevant information that would modify the status. I would suggest for the next time to use <https://ask.libreoffice.org>.
I would like this to be given deeper UX consideration. As a user, if I wanted to select the cells behind the comment, I would hide the comment first (and in that sense, this is related to bug #90577). It does not make sense to select individual cells that I cannot see, because I cannot see what I am acting on. I believe Z-ordering should be respected, and that manipulating objects should behave predictably with qualities similar to how things work in the physical world, and like in other UIs everywhere else (you don't expect right-clicking a popover or window to "click through" in any window manager, for example). The current behavior is contradicting many established UX principles throughout operating systems and applications.
(In reply to Jeff Fortin Tam from comment #3) > I would like this to be given deeper UX consideration. I am re-opening this report then. I will convert it from normal bug report to an enhancement request. I am also CC'ing Heiko. (In reply to Jeff Fortin Tam from comment #3) > if I > wanted to select the cells behind the comment, I would hide the comment > first While I understand your point, in practice such procedure would require more (unrelated, or not really needed) steps. With the current behavior, it is just 2 clicks (first left, then right), and there is no need to hide (and then display again) the comment (or any other object for that matter). It is a matter of practicality, and it is not _that_ strange nor unique either. (@Jeff, as a side note, you don't need to add yourself to every single report related to Calc comments; just add yourself to the relevant meta (tdf#101216 for example) and you will receive emails for all those reports.)
You gain some clicks, you lose some. It's a net zero at the end. For instance, your workflow requires users to do two clicks (or more) to intuitively get to the contextual menu of a comment (first a left click on the comment, then a right click on the comment; or first a right click, then realizing it doesn't work, then a left click, then a right-click). Otherwise, needing to know (and remember) that you must somehow right-click the comment's *cell* itself is not as intuitively discoverable/expected for changing the properties of a shown comment that is "right there in front of you"). Force-shown comments are like "physical" objects, they should behave as such. And it would be consistent with the rest of the application. Need proof of this principle being already applied even within LibreOffice? "Direct right-click" on an image or chart object selects & opens its context menu. It does not select the cells behind the chart/image. Yes, the more "standard expectation" / "consistent UX" I'm proposing here would require more clicks to accomplish your "select a cell behind a comment whose contents you cannot see" scenario; but do people actually (want to) do that in practice in the day-to-day? If moving/hiding the physical object out the way is "too many clicks", and you really want to still offer the ability to click-through while ignoring the visual z-ordering principle, then I believe it would make more sense for this behavior to be behind the `Alt` keyboard modifier, i.e. Alt+RightClick (which currently doesn't do anything on comments, and presumably would be a better choice than Ctrl+(Right-)Click or Shift+(Right-)Click). You could even apply that principle to images and charts too, if you want. > as a side note, you don't need to add yourself to every single report related to Calc comments; just add yourself to the relevant meta (tdf#101216 for example) and you will receive emails for all those reports.) Yup, I'm well acquainted with Bugzilla's features set :) however, doing so would not get me individual comment notifications from the sub-issues I care most about (that is why I subscribe to them), and I would get all the comments from SEO spammers that are posted onto the meta issue.
(In reply to Jeff Fortin Tam from comment #5) > You gain some clicks, you lose some. It's a net zero at the end. That's a stretch, to put it mildly. It is in no way a zero net balance. Generally speaking, less steps / clicks is usually better than requiring more steps, unless the same UI gets cluttered and/or "moving interactively". Every change has pros and cons. As with other procedures in LO/Calc, there are surely better ways to interact with the tool than the current ones. > > For instance, your workflow requires users to do two clicks (or more) to > intuitively get to the contextual menu of a comment (first a left click on > the comment, then a right click on the comment; or first a right click, then > realizing it doesn't work, then a left click, then a right-click). That is all a one-time occurrence, or none at all. Once you know how it works, it is always only 2 clicks. First select, then apply whichever action on the selected object(s). I wished other procedures in Calc were so simple. If the UX Team can make it better and consistent... > > > as a side note, you don't need to add yourself to every single report related to Calc comments; just add yourself to the relevant meta (tdf#101216 for example) and you will receive emails for all those reports.) > > Yup, I'm well acquainted with Bugzilla's features set :) however, doing so > would not get me individual comment notifications from the sub-issues I care > most about (that is why I subscribe to them), and I would get all the > comments from SEO spammers that are posted onto the meta issue. That is (by far) not accurate, while you are "polluting" unnecessary changes in a lot of reports (some of them with no relevant interaction for years). Oh well. Please let's patiently wait for the UX Team comments now.
> That is all a one-time occurrence, or none at all. > Once you know how it works, it is always only 2 clicks. Nope. I've known about this issue for 10+ years and I _still_ keep hitting it, as the behavior is counter to every other app, and even to other objects in LOo. I cannot "remember" it because it is inconsistent with everything else, and feels unnatural even on its own. It is not two clicks, it is four clicks every time you hit this bug: 1. Right-click: "Oh no, it clicked through the object I tried clicking on" 2. Left-click: the menu gets dismissed, but nothing gets selected. 3. Left click _again_ to select the object 4. Right-click _again_, and _then_ you finally get the menu. …and that's the case of "no-hesitation correction, without trial-and-error". There is also another flaw in your logic defending the current behavior: right-clicking a shown comment object clicks through to select the cell, but left-clicking does not "click through" the comment. Yet, by your logic, one could argue someone could want to select "the cell behind" using left click, without a menu appearing, for whatever reason. Z-order interaction behavior should be consistent whether it's right- or left-click. If you want alternate behavior, you use Alt. > You are "polluting" unnecessary changes in a lot of reports [...] Cross-linking topically related issues in a bug tracker has value. If you are rather talking about c.c. addition notifications, you can go to https://bugs.documentfoundation.org/userprefs.cgi?tab=email and untick "The CC field changes". Or use email filters.
(In reply to ady from comment #2) > Imagine that you actually want to select one of the cells that are covered > by the presence of the comment. With the current behavior, you can select > any cell, including those "behind" the comment. That is, either by > right-click, or by keyboard. Rather a positive fallout from a wrong implementation. I would never select per right-click. IMO, it's a bug.
(In reply to Heiko Tietze from comment #8) > IMO, it's a bug. Btw, you cannot right click through charts, shapes, or images.
(In reply to Heiko Tietze from comment #8) > Rather a positive fallout from a wrong implementation. I would never select > per right-click. Not my point. The point is: first select (i.e. right click), then apply whichever action. Not a new thing in Calc. Considering the current need to first select the comment as a bug is just "easy to say". The alternative must be an improvement in practical terms. As I said, every change has pros and cons.
I have now grabbed a coworker's computer to test Microsoft Excel out of curiosity, and it behaves exactly like I would expect to: right-clicking a "force-shown" note selects it and opens its contextual menu in one click. It never selects cells behind a shown note. Consistent with other object types in Excel and in LibreOffice Calc. I don't know where you are getting your usecase from to justify the current broken UX, but I at least now have certainty that it is not the industry standard and not what most users would expect.
(In reply to Jeff Fortin Tam from comment #11) > I don't know where you are getting your usecase from to justify the current > broken UX, but I at least now have certainty that it is not the industry > standard and not what most users would expect. I never claimed that the current behavior is used on Excel or any other tool. I am also not saying that Calc UX is the best in every aspect; it is certainly not. The only thing I said was that the current behavior in Calc is not unusual nor unexpected, generally speaking. I do understand that you might find it unexpected, but I disagree with users claiming (in some form or another) that "my experience, my expectations and my workflow are all, with no doubt, the same as everyone else". Is the current behavior broken and unexpected? Maybe some users might have such impression, but I would not agree with such statement. Is the current behavior strange, unusual, unexpected, broken? IMO, it is not. Could the current behavior be improved? Probably. Are there other places/features/artifacts in LO that behave in a similar way? Yes. Then consistency should be considered too; otherwise, the partial changes in procedures do result in "unexpected" behavior (because of inconsistency). I would not be surprised if, after changing this behavior, some other user reports that in "some older version" he could click on some cell and apply some action but in a new version some comment is selected instead. I just hope that changing this procedure won't end up requiring from users more steps than the current procedure, especially for the most frequent actions. As said, pros and cons, in every change.
Thanks for all your input. I think I'm with Jeff on this, mainly because of the following quotes: (In reply to Jeff Fortin Tam from comment #3) > It does not make > sense to select individual cells that I cannot see, because I cannot see > what I am acting on. (In reply to Jeff Fortin Tam from comment #5) > "Direct right-click" on an image or chart object selects & opens its context > menu. > It does not select the cells behind the chart/image. (In reply to Jeff Fortin Tam from comment #7) > Z-order interaction behavior should be consistent whether it's right- or > left-click. So consider me a +1. (In reply to ady from comment #6) > Please let's patiently wait for the UX Team comments now. Heiko has replied now, but in case others have an on changing a long-standing behaviour, adding keywords. I confirm that it's the same in OOo Calc 3.3. However, looking at consistency across components, note that current trunk's Impress _does_ allow right-clicking the numbered comment indicator without needing to first show the comment. It does not open the context menu for the page or whatever object is behind.
We discussed the topic in the design meeting and agree with the request. Respecting the z-order is superior to a few clicks. And besides, you can move a comment "out of the way" with one click.