Joined: Jun 20, 2006 Posts: 2051 Location: Midwest, USA
Posted: Mon May 13, 2013 11:58 am Post subject: Open Dialog Issues
Patrick:
I've been using NeoOffice Secure Edition for the last couple of days, and I've run into an issue with the Open dialog box.
I had 2-3 odt files open, each stored in a different folder on my hard drive.
I hit command-O and got the standard Open Dialog box, including the sidebar that mimics the sidebar in Finder windows. But clicking on folders in the sidebar does not shift the file list (on the right) to the contents of that folder. And the drop-down that lists the selected folder does not change. There's a brief screen flicker, during which the contents of the clicked-on folder appear for less than a second, but the list reverts to the folder listed in the drop-down. Similarly, when a folder on the left is clicked on, the name of the folder in the drop-down changes for less than a second, before reverting to the "original" folder name.
Attempting to use the drop-down menu to choose a parent folder of the listed folder has the same effect: the list and drop-down change for less than a second before reverting.
None of this happens in the standard NeoOffice edition.
I'm using Mountain Lion 10.8.3.
I installed one third-party extension to the Secure Edition, ConvertTextToNumber 1.4, which is an extension for Calc, and appears to work normally.
Joined: Jun 20, 2006 Posts: 2051 Location: Midwest, USA
Posted: Mon May 13, 2013 12:02 pm Post subject:
Two more additional pieces: If I hit the "cancel" button in the Save dialog, the dialog will close and then immediately reopen. If I hit "cancel" again, it will close and stay closed.
If I open a document from the Finder, when it opens in Neo SE, I also get an open dialog, this time with the drop-down set to the "share" folder (as in computer name>Hard Drive name>usr>share)
What you are seeing is the special native open dialog that NeoOffice Secure Edition uses when Apple's App Sandbox requires the user's explicit permission before NeoOffice Secure Edition is allowed to open a particular file or folder.
The one noticeable difference between this special "ask for permission from user" open dialog and the normal native open dialog is that the special open dialog will set the selected folder to the folder of the file that NeoOffice wants to access.
Once you press the OK button in the special open dialog, NeoOffice will be able to access the folder and its files and subfolders without having to display this open dialog again. However, if you cancel the special open dialog, you will see the special open dialog set the same folder every time NeoOffice Secure Edition's underlying OpenOffice.org code tries to access that same folder or one of its files.
What does seem unusual though is that you saw the special open dialog when you pressed the Command-O keys. That should display the regular native open dialog so can you remember if you only noticed the special dialog after you first saw the regular open dialog? In other words, did you see an open dialog more than once after pressing the Command-O keys?
I ask because there is one case where I can see an open dialog appearing more than once: in the regular native open dialog that gets displayed after pressing the Command-O keys, you select a document and press the OK button. If that document has a linked file in it, the special open dialog will appear for each unique folder that the document's linked files are located in.
Lorinda wrote:
Two more additional pieces: If I hit the "cancel" button in the Save dialog, the dialog will close and then immediately reopen. If I hit "cancel" again, it will close and stay closed.
I cannot reproduce that. Maybe you are using different steps than me? I opened a new, empty Writer document, input some text, selected the File :: Save menu, and cancelled the Save dialog that appeared.
Lorinda wrote:
If I open a document from the Finder, when it opens in Neo SE, I also get an open dialog, this time with the drop-down set to the "share" folder (as in computer name>Hard Drive name>usr>share)
You should not see any open dialog if "Hard Drive name" is the volume that Mac OS X booted from so I assume that, in your case, some code is trying to access a file on one of your other local volumes or remote machines. This is exactly what Apple's App Sandbox feature is designed for: to make you aware of applications that are silently accessing files on your machine.
The question is what is triggering this file access? Can you get the special open dialog to appear with the same folder? If so, can you take a sample of the NeoOffice process before you cancel the dialog? This should give us an idea of roughly which OpenOffice.org or extension's code is trying to access that folder.
FYI. When I mentioned "documents with linked files" in my last post, it generally means images that are not embedded in your document but, instead, are loaded from a separate image file on your machine.
You can determine if an image in your document is linked by right-clicking or Control-clicking on the image and in the popup menu that appears, selecting the Picture menu. In the dialog that appears, click on the Picture tab. Embedded images will have "[None]" in the "File name" field whereas linked images with have a full path to an image file.
Joined: Jun 20, 2006 Posts: 2051 Location: Midwest, USA
Posted: Tue May 14, 2013 7:47 am Post subject:
It will be later today before I can fire up the one machine I have with NO SE, so I'll get back to you on your questions a little later, but I did discover some more things after my last post yesterday that I can add now:
A new, untitled document saves just fine, without any oddities.
If I use "Save As" on that document after saving it once, I get the first save dialog with limited access, followed by the second one.
If I cancel out the first "Open" dialog (where I can't change the folder), the second Open dialog works just fine.
I get the "locked" Open dialog on both Save and Open commands.
Most of the documents I had open did not include images, and those that did had embedded, not linked images.
Most of the folders in question are subfolders of my Dropbox folder. Not sure if that makes a difference or not.
The location of the "share" folder I mentioned seeing when I open things from the Finder is a "hidden" folder: I went looking for it in Finder, and the folder "usr" is not visible where it "ought" to be based on the path specified in that open folder. I'll try to get you a screen shot of the dialog listing the files there, as I have a feeling the file names will mean more to you than to me, and may even tell you what file is being referred to.
Currently, it is not clear that the "locked" open dialog is asking permission to access the files, and that's why it won't let users go anywhere else in their file structure. For those of us used to "unSandboxed" apps, it's confusing: I'm guessing, though that you have no control over how that dialog appears, and given the "market" for NO SE, it may not matter much.
A new, untitled document saves just fine, without any oddities.
If I use "Save As" on that document after saving it once, I get the first save dialog with limited access, followed by the second one.
I can now reproduce this. I will investigate and see if I can track down what OpenOffice.org code is triggering this.
Lorinda wrote:
If I cancel out the first "Open" dialog (where I can't change the folder), the second Open dialog works just fine.
This I still cannot reproduce. Can you tell me what folder the "locked" dialog is set to in this particular case is and also take a sample of the NeoOffice process? From those two pieces of information, I can hopefully figure out what is triggering a locked dialog to appear before the regular native open dialog.
Lorinda wrote:
The location of the "share" folder I mentioned seeing when I open things from the Finder is a "hidden" folder: I went looking for it in Finder, and the folder "usr" is not visible where it "ought" to be based on the path specified in that open folder. I'll try to get you a screen shot of the dialog listing the files there, as I have a feeling the file names will mean more to you than to me, and may even tell you what file is being referred to.
I know what the folder is: it is /usr/share on a non-bootable volume. What I am interested in is what code is trying to read files in /usr/share on a non-bootable volume hence the request for a sample of the NeoOffice process when you see the locked dialog set to this particular folder.
I suspect that the extension that you have installed may be trying to silently read files. For extensions written in OpenOffice Basic, all file read and writes go through the same code that NeoOffice does so any file read or writes outside of Apple's App Sandbox's "safe" folders will trigger the locked dialog.
Lorinda wrote:
Currently, it is not clear that the "locked" open dialog is asking permission to access the files, and that's why it won't let users go anywhere else in their file structure. For those of us used to "unSandboxed" apps, it's confusing: I'm guessing, though that you have no control over how that dialog appears, and given the "market" for NO SE, it may not matter much.
In Apple's App Sandbox, the only way to ask the user for permission to access a file or folder is to present a native open or save dialog and have them press the OK button.
I implemented the "locking to a specific folder" behavior. Without my code, the locked dialogs would act the same as the regular native open dialogs. The reason that I added the folder locking code was because the locked open dialogs usually only appear when OpenOffice.org or extension code silently tries to read or write to a file that the user has not explicitly requested via the Finder or the regular native open or save dialogs. Since the locked open dialog is unexpected, I wanted the user to know exactly what folder they are granting access so I forced the locked open dialog to only allow selection of the folder that the code is trying to access.
Essentially, the user should be surprised to see the locked dialog as its main purpose is to make users aware of the fact that OpenOffice.org or extension code is silently trying to read and/or write to files. In other words, in NeoOffice Secure Edition, the user is now made aware of the file reads and writes that were hidden from them in NeoOffice, OpenOffice, and LibreOffice.
This locked dialog becomes really important in preventing malware. Specifically, extensions have a lot of potential for being a source of malware given ride on the coattails of our Apple Developer ID certificate to bypass the installation restrictions of Mac OS X 10.8's Gatekeeper. Once installed, extensions can read and write to any files. Apple's App Sandbox tries to limit the potential damage from extensions that are malware (or application code that is only accidentally destructive) by automatically denying read and write access to most files and folders unless the code displays a native open or save dialog and the user presses the OK button.
Joined: Jun 20, 2006 Posts: 2051 Location: Midwest, USA
Posted: Tue May 14, 2013 1:16 pm Post subject:
Ok. I've attached two samples: One while the locked Open dialog is open after hitting Command-O in NO SE. The other that happens after opening a file from the Finder.
Today, both dialogs showed the same folder in the drop-down, so I've only posted one screen shot. The folder in question is nested a few folders deep in my Dropbox, and one of the files I had open is located in that folder.
I could not reproduce the "share" folder location in the locked open dialog.
Lorinda
Note: These are all taken on the computer where I have installed the extension mentioned above
Thank you for the samples. Both indicate that the OpenOffice.org code is checking if a folder actually exists before displaying the regular native open dialog and this existence check is what is triggering the locked dialog to be displayed.
Display of the locked dialog when the File :: Save As menu is selected is also triggered by same folder existence check by the OpenOffice.org code before displaying the regular native save dialog.
I will investigate to see if I can skip these folder existence checks and, instead, detect non-existent folders when the regular native open or save dialog is displayed. I will post again when I have some progress to report.
Lorinda wrote:
I could not reproduce the "share" folder location in the locked open dialog.
You might need to delete your NeoOffice Secure Edition preferences folder to be able to reproduce that using the following step:
1. Quit NeoOffice Secure Edition
2. Move the following folder to the Trash or your Desktop. Note: "~" means your Home folder:
I think that I have found and bypassed the OpenOffice.org code that was causing our special "request access to folder" native open dialog to be displayed before the regular native open and save dialog are displayed.
Can you install the following test patch and tell us if you are still seeing any unexpected special "request access to folder" native open dialogs?:
Following this procedure before installing the test patch, I could reproduce the locked open dialog with the "share" folder as the location.
I did take a sample, but will not attach unless you indicate you need it.
After installing the test patch, I could not reproduce it.
The test patch has corrected the other occurrences of the locked open dialog I was seeing, too.
Following this procedure before installing the test patch, I could reproduce the locked open dialog with the "share" folder as the location.
I did take a sample, but will not attach unless you indicate you need it.
I definitely would like to look at the sample for the "share" folder if you can attach it. It will hopefully tell us if the OpenOffice.org code or extension code is trying to access particular folder.
Thank you for the sample. The sample indicates that the special open dialog was being triggered by the OpenOffice.org template folder search code. From this, I was able to reproduce what you see by selecting the File :: Templates :: Organize menu both with and without the test patch.
Since my experimentation with Apple's App Sandbox is that the /usr folder and its files and subfolders can be read by application's running in the App Sandbox without requiring any permission from the user, I will see if I can tweak our code to skip display of the special open dialog if for anything in the /usr folder.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
