Description: Track Changes toolbar opens automatically in a file with change tracking enabled, even when it was manually closed before. Actual Results: Track Changes toolbar opens automatically. Expected Results: The state of the panels is remembered and the panel does not appear. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: Version: 7.1.1.2 (x64) / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL
This was a solution for a serious security issue reported in Bug 83958. It would be possible to avoid this in the future by adding a Writer settings for it (reintroducing the security issue for the users). Could you give more information about your workflow? Do you use the experimental sidebar to handle tracked changes, that is why is this so annoying?
(In reply to László Németh from comment #1) > This was a solution for a serious security issue reported in Bug 83958. It > would be possible to avoid this in the future by adding a Writer settings > for it (reintroducing the security issue for the users). > > Could you give more information about your workflow? Do you use the > experimental sidebar to handle tracked changes, that is why is this so > annoying? Reproduced in a portable build taken from here - libreoffice.org/download/portable-versions. Default settings, after starting Writer I don't change anything. Bugappears appears on newly created documents with change tracking enabled. I did an experiment: I created 2 documents, 1.odt and 2.odt. In the first, I did not enable change tracking, in the second I did. If I open 1, then there is no panel. After closing and reopening the document, it does not appear again. And if you first open 2 (the panel appears), then close document and open 1, the panel remains on. I can't find anything about the experimental sidebar in the settings, sorry. But again, in the specified portable build, everything is by default from the moment of launch.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to László Németh from comment #1) > This was a solution for a serious security issue reported in Bug 83958. It > would be possible to avoid this in the future by adding a Writer settings > for it (reintroducing the security issue for the users). What is the security issue? Wasn't it a feature request from 2014? > Could you give more information about your workflow? Do you use the > experimental sidebar to handle tracked changes, that is why is this so > annoying? It is annoying - to me - because I hardly use / display toolbars. (I use keyboard shortcuts and menus. I am very pleased that Bug 115817 (the annoying pop-up of the Navigation Toolbar) will be fixed in 7.2.0.) As it is possible to choose not to show toolbars when selecting tables, images etc., it should also be possible to leave the Track Changes toolbar hidden when opening documents with tracked changes.
Sorry, but what does "automatic action" mean? None of the living people could reproduce? I just downloaded the portable LO 7.1.1 from the specified link, launched it and saw a spontaneously appearing change tracking panel in a document with change tracking enabled, while in LO 7.0.4 this does not happen! There the panel appears when I turn it on and disappears when I turn it off. This is literally what was broken back in 7.1.0.
as explained in comment 1, this is not an issue and it was done on purpose. Closing as RESOLVED WONTFIX
IMHO the argument in comment 1 is not correct: Bug 83958 is not a serious security issue. It was a request made in 2014 with no additional requests since then. The Track Changes toolbar should remain hidden when it was deliberately hidden via menu View - Toolbars, like all other toolbars do.
Let's add the UX team for a third opinion
The security question is up to Laszlo. I guess we need an indicator that everything being done is recorded via TC. If so, an alternative is to show an infobar. If we need the toolbar, how about to remember the previous state, meaning to not make it visible at the next session when it was enabled automatically?
(In reply to Heiko Tietze from comment #9) > If we need the toolbar, how about to remember the previous state...? I agree, that's the main point - if you need the bar, you turn it on manually, if you don't want to see the bar - you turn it off and it doesn't appear until you manually turn it on again. This is how I see it and this is how it worked before with TC bar.
(In reply to morfuinvorn from comment #10) > ...if you need the bar, you turn it on manually Sure, but if the toolbar needs to be activated automatically the idea was to not store whether it's on or off. Question to Laszlo: how about showing an infobar?
(In reply to Heiko Tietze from comment #12) > Question to Laszlo: how about showing an infobar? The question to Laszlo in the first place is: was Bug 83958 a serious security issue? (Its Importance field was set to "medium enhancement".)
(In reply to KeepTools from comment #13) > (In reply to Heiko Tietze from comment #12) > > Question to Laszlo: how about showing an infobar? > > The question to Laszlo in the first place is: was Bug 83958 a serious > security issue? (Its Importance field was set to "medium enhancement".) @morfuinvorn, KeepTools: thanks for the introduction of the use cases. @KeepTools: it could result serious privacy issues, but you are right, according the importance of the bug report and its history, it seems to be less important, than I thought. @Heiko: Indeed, infobar seems to be better. I'm going to check it.
Created attachment 171029 [details] Proposed infobar messages
Proposed fix: https://gerrit.libreoffice.org/c/core/+/113792 See the attached screenshots of the different infobar messages. tdf#141298 sw: show Track Changes infobar instead of enabling Track Changes toolbar automatically, when Track Changes toolbar is disabled, but the document contains recorded changes or Record Track Changes is enabled. Button of the Track Changes infobar allows to show/hide the Track Changes toolbar. Hiding the Track Changes toolbar with button of the Track Changes infobar closes the infobar, too. Regression from commit afbbfb3b55beb937555a972d9edbb47ede91001a "tdf#83958: sw: enable Track Changes toolbar automatically" and commit 1989201c56c03b1ef13a282cfd09af69620040ea "tdf#138870 sw: fix Track Changes toolbar reappearing".
(In reply to KeepTools from comment #7) > IMHO the argument in comment 1 is not correct: Bug 83958 is not a serious > security issue. It was a request made in 2014 with no additional requests > since then. No it *is* a privacy (not "security") issue: if one has a document with change tracking enabled, edits it and sends to another party, than the other party has all the document history, potentially not only the data they are entitled to see. You could have the track changes enabled in a document that you used as a "template" to create another document, and you send someone the data that was in a different document. Of course, it is when one has change tracking *not shown*, which is what tdf#125909 is about.
(In reply to László Németh from comment #16) > Proposed fix: https://gerrit.libreoffice.org/c/core/+/113792 > > See the attached screenshots of the different infobar messages. That would be a neat and useful solution. But it would better be restricted to the two situations: A) the document has recorded changes _and_ these changes are not shown. B) changes will be recorded _and_ these changes will not be shown. In other cases the infobar is not useful and would be “annoying” - IMO. (Especially because infobars cannot be removed with a keystroke; the mouse _must_ be used.) Secondly, I want to suggest to change the “Show/Hide Track Changes Functions”-button to a “Show Track changes toolbar”-button - which is only shown if the Track changes toolbar is not displayed already.
(In reply to Mike Kaganski from comment #17) > No it *is* a privacy (not "security") issue: if one has a document with > change tracking enabled, edits it and sends to another party, than the other > party has all the document history, potentially not only the data they are > entitled to see. I agree on that - from practical experience. An other option could be an indicator in the status bar, as implemented in an other much used text editor. As this small indicator has proven to be an insufficient warning for the privacy issue to me, the infobar would be appropriate.
Heh, so in the end, this seems to be a request to fix tdf#125909 literally like it has been worded initially: > Hidden tracking of changes might in some cases be a security issue, if one > sends a document which contains tracked information not supposed to be > available for recipient. > > Possibly when opening a document with hidden change tracking, an infobar > could be displayed, or a status bar icon (this still be mostly unnoticed > imo), or some other way of informing user about the mode (and how to > proceed)?
(In reply to Mike Kaganski from comment #20) > Heh, so in the end, this seems to be a request to fix tdf#125909 literally > like it has been worded initially: > > > Hidden tracking of changes might in some cases be a security issue, if one > > sends a document which contains tracked information not supposed to be > > available for recipient. It certainly does and I support this request. My apologies for my “protest” because I did not see this tdf before; only the reference to Bug 83958. Nonetheless we come to a better solution - imo.
(In reply to KeepTools from comment #18) > A) ... B) ... In other cases the infobar is not useful I think it is implemented like this. > Secondly, I want to suggest to change the “Show/Hide Track Changes > Functions”-button to a “Show Track changes toolbar”-button - which is only > shown if the Track changes toolbar is not displayed already. My proposal for the text: Track Changes: Document contains tracked changes and recording is enabled. [Show Toolbar] Track Changes: Recording of changes is enabled. [Show Toolbar] Track Changes: Document contains tracked changes. [Show Toolbar] Adding Seth since he always has good ideas for strings.
(In reply to Heiko Tietze from comment #22) > (In reply to KeepTools from comment #18) > > A) ... B) ... In other cases the infobar is not useful > > I think it is implemented like this. No it is not. Regardless of the enabled state of *showing* the tracked changes, the toolbar appears in any document with enabled tracking. That is how it was implemented in https://git.libreoffice.org/core/commit/afbbfb3b55beb937555a972d9edbb47ede91001a, and that is what this issue is about.
... but thinking further on this, I suppose that unconditional display of the infobar could still make sense. One could overlook the existing changes when opening a large document before sending, even if the changes are shown; so informing using an infobar looks safer (and yes, I realize that this would still not address the original problem raised here, so it should either be configurable, or a weighed decision comparing pro and contra).
@all: thanks for your reviews. Now the infobar depends on the disabled Show Changes, i.e. when there are/will be not visible recorded changes, according to Mike's and KeepTool's suggestion. I've fixed the messages according to Heiko's suggestion. Clicking on the button, its label "Show Toolbar" changed to "Hide Toolbar" to allow disabling the toolbar quickly after handling hidden track changes (e.g enabling Show Track Changes, disabling Record Track Changes or accepting/rejecting the recorded changes). I've added also tdf#125909 to the commit description, because this patch is really about Mike's original request.
(In reply to László Németh from comment #25) > @all: thanks for your reviews. > > Now the infobar depends on the disabled Show Changes, i.e. when there > are/will be not visible recorded changes, according to Mike's and KeepTool's > suggestion. > > I've fixed the messages according to Heiko's suggestion. > > Clicking on the button, its label "Show Toolbar" changed to "Hide Toolbar" > to allow disabling the toolbar quickly after handling hidden track changes > (e.g enabling Show Track Changes, disabling Record Track Changes or > accepting/rejecting the recorded changes). > > I've added also tdf#125909 to the commit description, because this patch is > really about Mike's original request. I would really plead to leave the Track changes toolbar hidden if it was previously hidden via Menu View - Toolbars. This is like all other context sensitive toolbars (like Image, Table, etc.) work in LO. ((By the way, beyond this scope: how about hidden text and hidden comments in a document? They may be copied unnotified as well.))
(In reply to KeepTools from comment #26) > (In reply to László Németh from comment #25) > > @all: thanks for your reviews. > > > > Now the infobar depends on the disabled Show Changes, i.e. when there > > are/will be not visible recorded changes, according to Mike's and KeepTool's > > suggestion. > > > > I've fixed the messages according to Heiko's suggestion. > > > > Clicking on the button, its label "Show Toolbar" changed to "Hide Toolbar" > > to allow disabling the toolbar quickly after handling hidden track changes > > (e.g enabling Show Track Changes, disabling Record Track Changes or > > accepting/rejecting the recorded changes). > > > > I've added also tdf#125909 to the commit description, because this patch is > > really about Mike's original request. > > I would really plead to leave the Track changes toolbar hidden if it was > previously hidden via Menu View - Toolbars. This is like all other context > sensitive toolbars (like Image, Table, etc.) work in LO. Unfortunately, Track Changes is not a content sensitive toolbar, but it would be nice to create a "semi-context sensitive" toolbar here, i.e. enabling it with the button of the infobar should be limited only for this document. "Hide Toolbar" button is only a quick workaround for this problem. > > ((By the way, beyond this scope: how about hidden text and hidden comments > in a document? They may be copied unnotified as well.)) Indeed. Maybe tt would be fine a "Document Inspector"-like feature.
(In reply to László Németh from comment #27) > Unfortunately, Track Changes is not a content sensitive toolbar, but > it would be nice to create a "semi-context sensitive" toolbar here, i.e. > enabling it with the button of the infobar should be limited only for this > document. "Hide Toolbar" button is only a quick workaround for this problem. How about turning it around: do not immediately change the Track changes toolbar's status and create a “_Show_ toolbar” button for the user who wants to make use of it? With the infobar the user is already notified - that was the main request. There is no need to display the Track changes toolbar too.
(In reply to KeepTools from comment #28) > (In reply to László Németh from comment #27) > > Unfortunately, Track Changes is not a content sensitive toolbar, but > > it would be nice to create a "semi-context sensitive" toolbar here, i.e. > > enabling it with the button of the infobar should be limited only for this > > document. "Hide Toolbar" button is only a quick workaround for this problem. > How about turning it around: do not immediately change the Track changes > toolbar's status and create a “_Show_ toolbar” button for the user who wants > to make use of it? With the infobar the user is already notified - that was > the main request. There is no need to display the Track changes toolbar too. This is the case now: Only the infobar is shown when Track changes toolbar is hidden, and Show Changes is disabled. But it's possible to enable the Track changes toolbar using the button of the infobar.
(In reply to László Németh from comment #29) > This is the case now: Only the infobar is shown when Track changes toolbar > is hidden, and Show Changes is disabled. But it's possible to enable the > Track changes toolbar using the button of the infobar. Well, if we want to be sure that the user is notified about tracked changes that are not shown as such, and/or that modifications will be unvisibly tracked, I think it is better not to rely on the visibility of the Track changes toolbar. The objective of tdf#125909 would be best met when the infobar is always displayed - in the situations described in comment #18.
(In reply to KeepTools from comment #30) > (In reply to László Németh from comment #29) > > This is the case now: Only the infobar is shown when Track changes toolbar > > is hidden, and Show Changes is disabled. But it's possible to enable the > > Track changes toolbar using the button of the infobar. > Well, if we want to be sure that the user is notified about tracked changes > that are not shown as such, and/or that modifications will be unvisibly > tracked, I think it is better not to rely on the visibility of the Track > changes toolbar. The objective of tdf#125909 would be best met when the > infobar is always displayed - in the situations described in comment #18. Likely you are right. I'm going to modify the patch, if it's ok to you.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d89786054715b44aa983d0752484216825c74ae2 tdf#125909 tdf#141298 sw: show (Hidden) Track Changes infobar It will be available in 7.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.
(In reply to László Németh from comment #31) > (In reply to KeepTools from comment #30) > > (In reply to László Németh from comment #29) > > > This is the case now: Only the infobar is shown when Track changes toolbar > > > is hidden, and Show Changes is disabled. But it's possible to enable the > > > Track changes toolbar using the button of the infobar. > > Well, if we want to be sure that the user is notified about tracked changes > > that are not shown as such, and/or that modifications will be unvisibly > > tracked, I think it is better not to rely on the visibility of the Track > > changes toolbar. The objective of tdf#125909 would be best met when the > > infobar is always displayed - in the situations described in comment #18. > > Likely you are right. I'm going to modify the patch, if it's ok to you. KeepTools, Heiko: I haven't done it, yet, but I will, if you think. Track Changes toolbar shows states of 1) Show Changes and 2) Recording, so the infobar could be a little bit redundant, i.e. annoying, but maybe only for the professional users.
(Sorry for the delay - I did not install a development version before.) I tested multiple scenarios, i.e. combinations of opening a document: - with a new / existing profile - with / without tracked changes - show changes enabled / disabled - record changes enabled / disabled The infobar popped up as expected, i.e. as described in comment #18. As finishing touch I want to share three remarks: • It feels more logical to show a button "Show changes" on the infobar, instead of (or in addition) to "Show toolbar". • Is the boldface "Track Changes" in the infobar in conformity with the UX guidelines? It could be left out imho; it is a bit blatant now. • When clicking the button "Show Toolbar", the toolbar pops up and the button text changes in "Hide Toolbar". Clicking this "Hide Toolbar" results in hiding the toolbar _and_ the infobar as well. Is this as intended? Thanks for your work - it is a useful notification!
(In reply to KeepTools from comment #34) > ...Is this as intended? Mind to create new tickets, one per topic? Labels are always good for a discussion. Would have to check with other infobars if the title is always bold. Buttons should close the infobar, IMHO. But this is up for discussion.
(In reply to Heiko Tietze from comment #35) > (In reply to KeepTools from comment #34) > Mind to create new tickets, one per topic? > > Labels are always good for a discussion. > Would have to check with other infobars if the title is always bold. > Buttons should close the infobar, IMHO. But this is up for discussion. It were suggestions to polish the -already nice- solution. I do not want to ask development time and energy for it by creating new tickets.