The "Review" tab has many functions that are relevant to comments, and changes tracking. Namely: - Comment - Reply Comment - Delete Comment - Format All Comments (only available in the "Tabbed Compact" mode, but I would want to see it available in the regular Tabbed mode too...) If I am inside that tab (in Tabbed or Tabbed Compact toolbar), LibreOffice should not switch me away from that tab automatically, yet this is what happens currently: - If I am in the page's contents, reviewing various tracked changes, and then I click inside a comment to edit the comment, it switches me away from the Review tab to the Home tab. - If I am inside a comment, and I would like to use the various comment-related functions, I switch to the Review tab... but as soon as I click away from the comment, it switches me back to the Home tab! That's a huge waste of time if you want to do that for multiple comments.
In fact this change, when entering/exiting a comment, switches you away from _any_ tab to the Home tab. So if you were in the "References" or "Insert" tabs, it'll switch you away from those too. At the end of the day, I'm not sure any auto-switching is a good idea unless you're selecting image/chart/form objects vs text.
Note that this happens not only in Writer, but in Calc too.
I'll confirm behavior. As for solution, Is rather see an option for auto-switching. If not feasible, better not to have it, rather leave what user selected.
In this particular case, clicking inside or outside a comment, you're going from the same "type" of content (text to text) so there should be no context switch triggered when the fundamental type is the same (unless comment management actions are added to the "Home" tab, but then it would get a bit crowded). Generally speaking (outside of this scenario), I would say that "an option for auto-switching" is not the approach I would recommend. Don't add options for things that should "just work". In theory either the app should not make a mistaken assumption, or it shouldn't do any switching at all, but I still think the auto-switching makes sense for some clear-cut cases (like when you select an image, chart, multimedia/audio/video, or form element, or index/references table).
Ok, you are right. No idea who could be invited or interested to look into this.
Dear Jean-François Fortin Tam, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
To answer the bot: problem is still present in Version: 7.5.2.2 (X86_64) Build ID: 50(Build:2) CPU threads: 8; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: fr-CA (en_CA.UTF-8); UI: en-US Calc: threaded
repro 24.2+ The same thing is true for switching between textbox content and the main body. The issue is that these are "editeng" components which have a different menu structure. At best we could see if both menus have the same "tab" and restore the tab after the menu switch.
NotebookbarTabControlBase::SetContext knows eLastContext, and is passed vcl::EnumContext::Context::Default when it is deactivated (but LOKit doesn't deactive). Then it activates with a real context, which always seems to match HOME if it doesn't have a specific tab (so even skipping deactivation won't help). If the current tab is vcl::EnumContext::Context::Any, then we don't want to switch to another ANY control. ANY pages are always visible.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7626e37b7c77980ba41bdc7e9131b9c373dea038 tdf#141136 NBB SetContext: don't SetCurPageId twice for the same page It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9f5393abea012be04ab7ecb26d8031019bc50f62 tdf#141136 NBB SetContext: try to stay on the same tab It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/805abacd0d1fe2d5522a2041fc3c07961a62ba5f related tdf#68695 tdf#141136 sc: comment can't resize; avoid context change It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm going to mark this bug report as fixed. The general fix handles the reported issue in Writer, and a specific fix mitigates jump when entering a comment in calc (and exiting the comment also is not causing a jump). I'm sure there are many more instances where tab jumping occurs. Those should be reported separately, as likely each one will need a unique patch. Please do not report an "unwanted jump" when it jumps to a "newly visible tab", as that is a context jump and is generally intended and desirable. Only report "jumps to the home tab" from a regular tab that is always visible.