Issue 122082

Summary: [sidebar] Some items enabled on read-only documents
Product: General Reporter: Ariel Constenla-Haile <arielch>
Component: codeAssignee: Andre <awf.aoo>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: issues, orw
Version: 4.0.0-dev   
Target Milestone: 4.0.0   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 121420    
Attachments:
Description Flags
Screenshot - read-only text document
none
Writer document with protected content
none
Screenshot none

Description Ariel Constenla-Haile 2013-04-17 17:59:40 UTC
Created attachment 80542 [details]
Screenshot - read-only text document

New writer document
Type dt and press F3 to insert dummy text
Save the document and close it
Open the document, checking the "Read-only" checkbox

Bug: several items in the text property panel are enabled
Comment 1 Oliver-Rainer Wittmann 2013-04-22 13:29:54 UTC
Andre, please take over.

As discussed, a general panel configuration which hides the complete panel in 'read-only document context' would make sense to solve this issue.
Comment 2 Oliver-Rainer Wittmann 2013-04-22 13:37:35 UTC
described defect not limited to Writer, also in Draw/Impress and Calc the one or the other property panel contains active controls in 'read-only document context'
Comment 3 Andre 2013-04-23 13:26:03 UTC
Best solution is probably this:

1. Hide complete panels when they are not fully operational in read-only mode.  
2. Gray out/disable the tab bar button when all panels are disabled because of the read-only mode.
3. Add a flag to Sidebar.xcs that lets panel implementations declare whether they can be used in read-only mode.
Comment 4 SVN Robot 2013-04-29 08:44:45 UTC
"af" committed SVN revision 1476921 into trunk:
122082: Hide sidebar panels for read only documents.
Comment 5 Andre 2013-04-29 08:44:57 UTC
Fixed as described above. The name of the XCS flag is ShowForReadOnlyDocument.
Comment 6 Ariel Constenla-Haile 2013-05-02 22:17:49 UTC
Created attachment 80627 [details]
Writer document with protected content

The document has a the following protected content:

- a protected section
- a table with some protected cells
- a frame with protected content

Placing the cursor inside the protected content, the toolbar items are disabled, but the sidebar's properties panel has some items enabled.

Shall I open a new bug for protected document content or reuse this one (adapting the summary)?
This one handles only the read-only document case.
Comment 7 Oliver-Rainer Wittmann 2013-05-03 06:04:20 UTC
(In reply to comment #6)
> Created attachment 80627 [details]
> Writer document with protected content
> 
> The document has a the following protected content:
> 
> - a protected section
> - a table with some protected cells
> - a frame with protected content
> 
> Placing the cursor inside the protected content, the toolbar items are
> disabled, but the sidebar's properties panel has some items enabled.
> 
> Shall I open a new bug for protected document content or reuse this one
> (adapting the summary)?
> This one handles only the read-only document case.

+1 for submitting a new bug
Comment 8 Ariel Constenla-Haile 2013-05-04 17:10:24 UTC
Reopening.

New writer document
Type dt and press F3 to insert dummy text
Save the document and close it
Open the document, checking the "Read-only" checkbox
The sidebar displays the Navigator only, all other panels are disabled (side bug: the panel title is "Properties (Text)", though the Navigator is activated)

Press "Edit File" from the standard toolbar (.uno:EditDoc), the document will be editable, and all toolbar items are enabled

Bug: the sidebar does not react to this, it is still in its "read-only" mode, showing only the navigator.
Comment 9 Ariel Constenla-Haile 2013-05-04 17:12:01 UTC
(In reply to comment #6)
> Created attachment 80627 [details]
> Writer document with protected content
> 
> The document has a the following protected content:
> 
> - a protected section
> - a table with some protected cells
> - a frame with protected content
> 
> Placing the cursor inside the protected content, the toolbar items are
> disabled, but the sidebar's properties panel has some items enabled.
> 
> Shall I open a new bug for protected document content or reuse this one
> (adapting the summary)?
> This one handles only the read-only document case.

For now I won't open a new one, the solution for bug described in comment 8 might be the same.
Comment 10 Andre 2013-05-08 12:22:41 UTC
Re comment 6: This is probably related to the incomplete support of all the various slot/command states.  The read-only flag would be one of them but our (my) solution is per-panel, not per-slot, and therefore not applicable to other flags.


Re comment 8: I can reproduce the wrong deck title but not the missing update after "Edit File".
Comment 11 Andre 2013-05-08 12:37:27 UTC
Fixed the wrong deck title (and missing tab bar highlight).  Looked like caused by bit rot: too many modifications transferred from git to svn via patches.
Comment 12 SVN Robot 2013-05-08 12:39:16 UTC
"af" committed SVN revision 1480250 into trunk:
122082: Show correct deck title and tab bar highlight after switching sidebar...
Comment 13 SVN Robot 2013-05-10 08:51:18 UTC
"af" committed SVN revision 1480937 into trunk:
122082: Disable controls of text property sidebar panel for disabled document...
Comment 14 SVN Robot 2013-05-10 09:00:59 UTC
"af" committed SVN revision 1480942 into trunk:
122082: Remove temporary change.
Comment 15 SVN Robot 2013-05-10 13:21:07 UTC
"af" committed SVN revision 1481006 into trunk:
122082: Reverting accidental modification.
Comment 16 Andre 2013-05-10 13:22:19 UTC
Setting this again to 'fixed' because
- the read-only part should be covered by deactivating most panels
- I can not reproduce the missing activation of panels after a read-only document is made read-write
- the TextPropertyPanel now handles text that is protected.

But other panels still don't handle protected text (or disabled slots, but that is another issue): the way the Symphony panels handle slots and items is a mess.  Everything is explicitly spelled out instead of using already existing toolbar/toolbox item controllers.  Set the insert/InsertPropertyPanel of how this could be done differently.
Comment 17 Ariel Constenla-Haile 2013-05-17 03:20:07 UTC
(In reply to comment #16)
> - I can not reproduce the missing activation of panels after a read-only
> document is made read-write

What steps are you following? This isn't reproducible if the file is read-only (missing user rights, or the like). But if you follow the steps in comment 8, this is still reproducible. There is a big difference in .uno:EditDoc if the file is read-only or the document was just opened read-only by checking the filepicker box:

Test A:

New writer document
Type dt and press F3 to insert dummy text
Save the document and close it
Open the document, checking the "Read-only" checkbox
The sidebar displays the Navigator only, all other panels are disabled
Press "Edit File" from the standard toolbar (.uno:EditDoc), the document will be editable, and all toolbar items are enabled

Bug: the sidebar does not react to this, it is still in its "read-only" mode, showing only the navigator.

This is still reproducible on current trunk.


Test B (sorry, Linux instruction to set the file read-only):

New writer document
Type dt and press F3 to insert dummy text
Save the document and close it
Change the file permissions: chmod -w </tmp/Untitled\ 1.odt>
Open the document. It is read-only.
Press "Edit File" from the standard toolbar (.uno:EditDoc), an InfoBox asks you if you want to edit a copy, press "Yes" to confirm.

There is no bug here, it is another document. In Test A it is the same document, it's not even reloaded.
Listening for status updates of ".uno:EditDoc" is good, but in sfx2::sidebar::SidebarController::statusChanged() 

SwitchToDeck(msCurrentDeckId);

doesn't do much. It should update the whole configuration.
Comment 18 Ariel Constenla-Haile 2013-05-17 03:31:45 UTC
Created attachment 80703 [details]
Screenshot

Document with user access rights, but opened read-only, as explained in comment 6

After selecting .uno:EditDoc in the toolbar, the document switches to edit mode, but the sidebar does not reflect this.
Comment 19 Ariel Constenla-Haile 2013-05-17 03:39:08 UTC
(In reply to comment #18)
> Created attachment 80703 [details]
> Screenshot
> 
> Document with user access rights, but opened read-only, as explained in
> comment 6

Here I meant comment 8

> After selecting .uno:EditDoc in the toolbar, the document switches to edit
> mode, but the sidebar does not reflect this.

The other way around (from edit mode to read-only) does not work either:

- Open a Writer document in edit mode (simply don't check read-only on the file picker). The toolbar item for .uno:EditDoc is checked
- Switch to read-only mode by pressing .uno:EditDoc
- We are back to "some items enabled on read-only document", now the Text properties panel is working fine, but the Paragraph and Page properties not.
Comment 20 Ariel Constenla-Haile 2013-05-17 03:49:20 UTC
(In reply to comment #16)
> - the read-only part should be covered by deactivating most panels
> - I can not reproduce the missing activation of panels after a read-only
> document is made read-write

I still see the problem on both sides:
- doc opened in read-only mode, then switched to edit mode
- doc opened in edit mode, then switched to read-only mode

> But other panels still don't handle protected text (or disabled slots, but
> that is another issue)

I opened bug 122330
Comment 21 SVN Robot 2013-05-17 11:13:53 UTC
"af" committed SVN revision 1483739 into trunk:
122082: React to changes read-only <-> read-write more realiably.
Comment 22 Andre 2013-05-17 11:19:35 UTC
Yes, I missed the variant of changing the read-write flag where the document is not replaced.

I fixed this by forcing an update of the current deck by calling UpdateConfiguration() not just SwitchToDeck().  This call is now also made asynchronously to avoid problems/assertions by calling back into sfx2 from within an SfxBindings::Udpate().
Comment 23 Andre 2013-05-17 12:23:50 UTC
Setting status back to fixed.