From dalibor.topic at oracle.com Mon Sep 2 04:18:49 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 02 Sep 2013 13:18:49 +0200 Subject: Building JDK7 on OS X 10.6.8 In-Reply-To: <52218D92.7090502@gmail.com> References: <52218D92.7090502@gmail.com> Message-ID: <52247419.3010503@oracle.com> On 8/31/13 8:30 AM, Andrew ``Bass'' Shcheglov wrote: > Also, once the patch looks good to you, would it be possible to merge it > into the main code tree? Not into JDK 7u, as such, as for that it would need to go into 8 first. For an experimental porting effort, the BSD Porting Project would be a better home, if the code is covered under an OCA[0], and if the port's developers accept it. cheers, dalibor topic [0] See http://openjdk.java.net/contribute/ step 0. -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From alexandr.scherbatiy at oracle.com Thu Sep 5 07:59:17 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 05 Sep 2013 18:59:17 +0400 Subject: [8] Review request for 8008728 [macosx] Swing. JDialog. Modal dialog goes to background Message-ID: <52289C45.8040609@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008728 webrev: http://cr.openjdk.java.net/~alexsch/8008728/webrev.00 Suppose there are 2 frames and one modal dialog which has the first frame as a parent. When we click on the second window the canBecomeMainWindow method returns NO (the second window is disabled because of the modal dialog) and it does not receive the windowDidBecomeMain event. But Mac OS X system places the second window over the modal dialog. The fix checks the right order of windows in the canBecomeMainWindow method. Thanks, Alexandr. From brent.christian at oracle.com Thu Sep 5 14:30:24 2013 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 05 Sep 2013 14:30:24 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] Message-ID: <5228F7F0.8080605@oracle.com> Please review my changes for 7199674 (http://bugs.sun.com/view_bug.do?bug_id=7199674). This improves how Java .app bundles work when they've been signed for the Mac App Sandbox. Specifically, it changes how the user.home system property is set. For apps signed for the App Sandbox, user.home will point to an accessible location within the App's sandbox container. (If not signed for the App Sandbox, user.home still points to the user's home directory). This is in line with how Mac sandbox-ed apps are expected to work (they are not permitted access to a user's "real" home directory). For reference, an overview of the Mac App Sandbox is at [1], and this specific point comes from [2]: "If you are using a POSIX function such as getpwuid to obtain the path to the user?s actual home directory from directory services (rather than by using the HOME environment variable), consider instead using a Cocoa or Core Foundation symbol such as the NSHomeDirectory function. By using Cocoa or Core Foundation, you support the App Sandbox restriction against directly accessing the user?s home directory." I have confirmed that my change works as expected under the Mac App Sandbox. I bundled my test case a Mac .app, and signed it with the "com.apple.security.app-sandbox" entitlement. When the signed app is run, my usual home directory is reported as !File.canRead(), and the user.home property returns a path under ~/Library/Containers/, which is readable. I plan to label this as "noreg-hard" - signing an .app bundle requires Keychain setup for any machine running the test. Webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/ (One note - the change to make/common/Defs-macosx.gmk is not, strictly speaking, part of this fix, but was necessary for the "old build" to finish on my OS X 10.8.4 system. I've left it in.) An automated build+test run shows no (new) problems. Thanks, -Brent [1] http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html [2] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html From Alan.Bateman at oracle.com Fri Sep 6 02:27:04 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 10:27:04 +0100 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5228F7F0.8080605@oracle.com> References: <5228F7F0.8080605@oracle.com> Message-ID: <52299FE7.2050702@oracle.com> On 05/09/2013 22:30, Brent Christian wrote: > : > > I plan to label this as "noreg-hard" - signing an .app bundle requires > Keychain setup for any machine running the test. > > Webrev is here: > http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/ > > (One note - the change to > make/common/Defs-macosx.gmk > is not, strictly speaking, part of this fix, but was necessary for the > "old build" to finish on my OS X 10.8.4 system. I've left it in.) I don't know Cocoa memory management but from a quick look at the NSAutoreleasePool docs then what you seems to be right. Folks on macosx-port-dev would be better to comment on that. I see that createUTF8CString doesn't handle malloc failing and it's not clear how CFStringGetCString behaves when called with NULL. In any case, this is all early startup and if we have malloc failing this early then we aren't going to get very far. One comment on the error case (fallback to "?") as this is now duplicated. It might be better to have this fallback in one place (GetJavaProperties) as I'm pretty sure we'll need to re-examine it at some point (we periodically hear about environments where user.name/user.home end up as "?", it's been mis-configured systems in all cases that I've looked at but arguably we should fail rather than use "?"). The update to the old build is only interesting if this is back-ported to jdk7u. Hopefully Erik or someone in the build team will be allowed to set their phasers to kill soon. -Alan. From nick at transparentech.com Fri Sep 6 03:24:21 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Fri, 6 Sep 2013 12:24:21 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <52299FE7.2050702@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> Message-ID: As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change. It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox. Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents). So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated. I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler Nick On Fri, Sep 6, 2013 at 11:27 AM, Alan Bateman wrote: > On 05/09/2013 22:30, Brent Christian wrote: > >> : >> >> I plan to label this as "noreg-hard" - signing an .app bundle requires >> Keychain setup for any machine running the test. >> >> Webrev is here: >> http://cr.openjdk.java.net/~**bchristi/7199674/webrev.00/ >> >> (One note - the change to >> make/common/Defs-macosx.gmk >> is not, strictly speaking, part of this fix, but was necessary for the >> "old build" to finish on my OS X 10.8.4 system. I've left it in.) >> > I don't know Cocoa memory management but from a quick look at the > NSAutoreleasePool docs then what you seems to be right. Folks on > macosx-port-dev would be better to comment on that. > > I see that createUTF8CString doesn't handle malloc failing and it's not > clear how CFStringGetCString behaves when called with NULL. In any case, > this is all early startup and if we have malloc failing this early then we > aren't going to get very far. > > One comment on the error case (fallback to "?") as this is now duplicated. > It might be better to have this fallback in one place (GetJavaProperties) > as I'm pretty sure we'll need to re-examine it at some point (we > periodically hear about environments where user.name/user.home end up as > "?", it's been mis-configured systems in all cases that I've looked at but > arguably we should fail rather than use "?"). > > The update to the old build is only interesting if this is back-ported to > jdk7u. Hopefully Erik or someone in the build team will be allowed to set > their phasers to kill soon. > > -Alan. > From Alan.Bateman at oracle.com Fri Sep 6 06:38:47 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 06 Sep 2013 14:38:47 +0100 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> Message-ID: <5229DAE7.80307@oracle.com> On 06/09/2013 11:24, Nicholas Rahn wrote: > As someone with a Java app in the Mac App Store (MAS), I would like to > vote against this change. > > It is still important to know the user's actual home directory > (/Users/) even if the app is running in the sandbox. Using > the entitlement, com.apple.security.files.user-selected.read-write, we > can still write to user selected directories (such as ~/Documents). > So changing the user.home property to point to somewhere in the app's > Container would make it more difficult to get the actual home > directory and thus, other directories that the end-user is familiar > with. I also think this change would lead to more developer confusion > and make application code more complicated. > > I don't know all what the user.home property is used for in the JDK > itself, but concerns about the MAS sandbox would be, IMHO, better > handled using special Mac/MAS only properties, such as those setup by > infinitekind's Appbundler fork on bitbucket: > https://bitbucket.org/infinitekind/appbundler > > Nick I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory. FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then. -Alan. From david.dehaven at oracle.com Fri Sep 6 09:18:31 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 6 Sep 2013 09:18:31 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5229DAE7.80307@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: >> As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change. >> >> It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox. Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents). So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated. >> >> I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler >> >> Nick > I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory. > > FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then. I haven't had a chance to look at the changes yet, so this may be a bit premature... Using NSHomeDirectory is the CORRECT behavior, whether the app is sandboxed or not (that extends to ALL apps, not just Java based). If the application needs to access Documents, Music, Movies, etc then those entitlements need to be added. Additionally, even if sandboxed an application can open documents in any folder the user has access to as long as the standard file chooser is used (which I believe we already do), the app will be granted (indirect) access to the selected file(s). -DrD- From nick at transparentech.com Fri Sep 6 14:17:16 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Fri, 6 Sep 2013 23:17:16 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: If you're saying that NSHomeDirectory is the correct behaviour for the Java user.home property, then I have to disagree. On every other platform, including non-sandboxed Mac, user.home is the actual user's home directory (i.e. /home/ or /Users/ or C:\Users\). Setting user.home to the *application's* home directory (which is what NSHomeDirectory returns in a sandboxed environment) would seem to me to break the definition of the user.home property. On a mac, in a sandboxed and non-sandboxed environment, I would expect user.home to be NSHomeDirectoryForUser. A sandboxed Java app definitely needs to know about the app's Container directory (and even whether it's actually being run sandboxed or not), but redefining user.home doesn't seem like the right solution. Having AppBundler (or even the JRE) provide that information via special properties feels better from my developer's perspective. Nick On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote: > > >> As someone with a Java app in the Mac App Store (MAS), I would like to > vote against this change. > >> > >> It is still important to know the user's actual home directory > (/Users/) even if the app is running in the sandbox. Using the > entitlement, com.apple.security.files.user-selected.read-write, we can > still write to user selected directories (such as ~/Documents). So > changing the user.home property to point to somewhere in the app's > Container would make it more difficult to get the actual home directory and > thus, other directories that the end-user is familiar with. I also think > this change would lead to more developer confusion and make application > code more complicated. > >> > >> I don't know all what the user.home property is used for in the JDK > itself, but concerns about the MAS sandbox would be, IMHO, better handled > using special Mac/MAS only properties, such as those setup by > infinitekind's Appbundler fork on bitbucket: > https://bitbucket.org/infinitekind/appbundler > >> > >> Nick > > I'm sure Brent wants to do the right thing here and maybe this needs > some input from the Apple or other Mac-savvy folks as to whether sandboxed > apps are really supposed to know about the actual user's home directory. > > > > FWIW, the original recommendaiton to switch to NSHomeDirectory came from > Scott Kovatch when he was working on Application Bundler. It's very > possible that things have changed since then. > > > I haven't had a chance to look at the changes yet, so this may be a bit > premature... > > > Using NSHomeDirectory is the CORRECT behavior, whether the app is > sandboxed or not (that extends to ALL apps, not just Java based). > > If the application needs to access Documents, Music, Movies, etc then > those entitlements need to be added. Additionally, even if sandboxed an > application can open documents in any folder the user has access to as long > as the standard file chooser is used (which I believe we already do), the > app will be granted (indirect) access to the selected file(s). > > -DrD- > > From brent.christian at oracle.com Fri Sep 6 17:08:56 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 06 Sep 2013 17:08:56 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: <522A6E98.1060101@oracle.com> Hi, Nick. Thanks for your feedback. I'm glad to hear from someone who has experience with App Store deployment. On 9/6/13 2:17 PM, Nicholas Rahn wrote: > If you're saying that NSHomeDirectory is the correct behaviour for the Java > user.home property, then I have to disagree. On every other platform, > including non-sandboxed Mac, user.home is the actual user's home directory > (i.e. /home/ or /Users/ or C:\Users\). NSHomeDirectory still returns /Users/ on non-sandboxed Mac. From my testing today, it seems the native Mac file dialog (which underlies java.awt.FileDialog) does understand the "sandboxed" NSHomeDirectory path. If you FileDialog.setDirectory() to it, the dialog comes up showing /Users/. This also works directories contained in ~, such as ~/Documents. (All this requires com.apple.security.files.user-selected.[read-only|read-write], of course). So that's a bit surprising, though it does mean that: String userHomePath = System.getProperty("user.home"); myFileDialog.setDirectory(userHomePath + "/Documents"); will give you a FileDialog pointing to ~/Documents whether or not you're running in the sandbox. My understanding is that, when sandboxed, the *only* way to access files within the User's "real" home directory is by selecting them in the native file browser. And of course at that point, you can get the path from the selected file. The difference, then, is how user.home can be used outside the context of a FileDialog. Currently, I think the answer when running in the sandbox is "it can't" (unless there are other Entitlements that would make the path to ~ accessible). So the thinking here is that there is more value in having user.home reflect an accessible location. > Setting user.home > to the *application's* home directory (which is what NSHomeDirectory > returns in a sandboxed environment) would seem to me to break the > definition of the user.home property. > > On a mac, in a sandboxed and non-sandboxed environment, I would expect > user.home to be NSHomeDirectoryForUser.> I can look into NSHomeDirectoryForUser. NSHomeDirectory was used because it's what is mentioned in the Apple documentation I've seen regarding the App Sandbox. > A sandboxed Java app definitely > needs to know about the app's Container directory (and even whether it's > actually being run sandboxed or not), but redefining user.home doesn't seem > like the right solution. Having AppBundler (or even the JRE) provide that > information via special properties feels better from my developer's > perspective. Adding an additional special property may or may not fly, but I can look into it. Thanks, -Brent > On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote: > >> >>>> As someone with a Java app in the Mac App Store (MAS), I would like to >> vote against this change. >>>> >>>> It is still important to know the user's actual home directory >> (/Users/) even if the app is running in the sandbox. Using the >> entitlement, com.apple.security.files.user-selected.read-write, we can >> still write to user selected directories (such as ~/Documents). So >> changing the user.home property to point to somewhere in the app's >> Container would make it more difficult to get the actual home directory and >> thus, other directories that the end-user is familiar with. I also think >> this change would lead to more developer confusion and make application >> code more complicated. >>>> >>>> I don't know all what the user.home property is used for in the JDK >> itself, but concerns about the MAS sandbox would be, IMHO, better handled >> using special Mac/MAS only properties, such as those setup by >> infinitekind's Appbundler fork on bitbucket: >> https://bitbucket.org/infinitekind/appbundler >>>> >>>> Nick >>> I'm sure Brent wants to do the right thing here and maybe this needs >> some input from the Apple or other Mac-savvy folks as to whether sandboxed >> apps are really supposed to know about the actual user's home directory. >>> >>> FWIW, the original recommendaiton to switch to NSHomeDirectory came from >> Scott Kovatch when he was working on Application Bundler. It's very >> possible that things have changed since then. >> >> >> I haven't had a chance to look at the changes yet, so this may be a bit >> premature... >> >> >> Using NSHomeDirectory is the CORRECT behavior, whether the app is >> sandboxed or not (that extends to ALL apps, not just Java based). >> >> If the application needs to access Documents, Music, Movies, etc then >> those entitlements need to be added. Additionally, even if sandboxed an >> application can open documents in any folder the user has access to as long >> as the standard file chooser is used (which I believe we already do), the >> app will be granted (indirect) access to the selected file(s). >> >> -DrD- >> >> From krueger at lesspain.de Sun Sep 8 03:44:06 2013 From: krueger at lesspain.de (=?UTF-8?Q?Robert_Kr=C3=BCger?=) Date: Sun, 8 Sep 2013 12:44:06 +0200 Subject: Possible regression: FileDialog allowing selection of files with apple.awt.fileDialogForDirectories == true Message-ID: Hi, for ages we have been using the following approach to show a native file dialog to choose a directory: FileDialog fileDialog = .....; fileDialog.setMode(FileDialog.LOAD); try { System.setProperty("apple.awt.fileDialogForDirectories", "true"); fileDialog.setVisible(true); } finally { System.setProperty("apple.awt.fileDialogForDirectories", "false"); } Now I noticed with build 103 that this allows me to select files as well. Starting the same application with Apple's JDK 6 behaves as expected. I cannot prove this right now but I am quite sure that I specifically tested this with an OpenJDK 8 build a few months ago and it worked. So this appears like a regression but I might be wrong. Is this known or should I file a bug report? Regards, Robert From paul_t100 at fastmail.fm Sun Sep 8 08:31:24 2013 From: paul_t100 at fastmail.fm (Paul Taylor) Date: Sun, 08 Sep 2013 16:31:24 +0100 Subject: Possible regression: FileDialog allowing selection of files with apple.awt.fileDialogForDirectories == true In-Reply-To: References: Message-ID: <522C984C.60900@fastmail.fm> On 08/09/2013 11:44, Robert Kr?ger wrote: > Hi, > > for ages we have been using the following approach to show a native > file dialog to choose a directory: > > FileDialog fileDialog = .....; > > fileDialog.setMode(FileDialog.LOAD); > try { > System.setProperty("apple.awt.fileDialogForDirectories", "true"); > fileDialog.setVisible(true); > } finally { > System.setProperty("apple.awt.fileDialogForDirectories", "false"); > } > > Now I noticed with build 103 that this allows me to select files as > well. Starting the same application with Apple's JDK 6 behaves as > expected. I cannot prove this right now but I am quite sure that I > specifically tested this with an OpenJDK 8 build a few months ago and > it worked. So this appears like a regression but I might be wrong. > > Is this known or should I file a bug report? > > Regards, > > Robert > I call System.setProperty() first before I construct the fileDialog I don't know if that makes any difference. But that works for me using 7u40 Build b40 Paul From alexandr.scherbatiy at oracle.com Mon Sep 9 03:44:10 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 09 Sep 2013 14:44:10 +0400 Subject: Possible regression: FileDialog allowing selection of files with apple.awt.fileDialogForDirectories == true In-Reply-To: <522C984C.60900@fastmail.fm> References: <522C984C.60900@fastmail.fm> Message-ID: <522DA67A.1030505@oracle.com> The "apple.awt.fileDialogForDirectories" property implementation has been added as fix for the issue 7161437 [macosx] awt.FileDialog doesn't respond appropriately for mac when selecting folders http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7161437 The value of the "apple.awt.fileDialogForDirectories" property is set to the NSOpenPanel by setCanChooseDirectories method: https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/Classes/NSOpenPanel_Class/Reference/Reference.html#//apple_ref/occ/instm/NSOpenPanel/setCanChooseDirectories: You can submit the bug that there is the difference of "apple.awt.fileDialogForDirectories" property usage between Apple JDK and OpenJDK on http://bugreport.sun.com/bugreport/ page. Thanks, Alexandr. On 9/8/2013 7:31 PM, Paul Taylor wrote: > On 08/09/2013 11:44, Robert Kr?ger wrote: >> Hi, >> >> for ages we have been using the following approach to show a native >> file dialog to choose a directory: >> >> FileDialog fileDialog = .....; >> >> fileDialog.setMode(FileDialog.LOAD); >> try { >> System.setProperty("apple.awt.fileDialogForDirectories", "true"); >> fileDialog.setVisible(true); >> } finally { >> System.setProperty("apple.awt.fileDialogForDirectories", "false"); >> } >> >> Now I noticed with build 103 that this allows me to select files as >> well. Starting the same application with Apple's JDK 6 behaves as >> expected. I cannot prove this right now but I am quite sure that I >> specifically tested this with an OpenJDK 8 build a few months ago and >> it worked. So this appears like a regression but I might be wrong. >> >> Is this known or should I file a bug report? >> >> Regards, >> >> Robert >> > I call System.setProperty() first before I construct the fileDialog I > don't know if that makes any difference. > But that works for me using 7u40 Build b40 > > Paul From leonid.romanov at oracle.com Mon Sep 9 04:20:14 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Mon, 9 Sep 2013 15:20:14 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Message-ID: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> Hello, This is a bug with a long history. It all started with 1* followed by 2*. What looked like a perfectly fine approach back then has caused us a number of problems ever since, like 3* and all the other similar menu related issues that followed. JDK-8020209 is the latest in the series. What happens in JDK-8020209 is that Cocoa calls -performKeyEquivalent twice: first for "Cmd =" followed by the call for "Cmd +". If you look at all these bugs, it will become evident that the crux of the problem is that we use -performKeyEquivalent to intercept key events that don't go through -keyDown, so this patch is an attempt to fix it. In order to make these events to go through -keyDown, I have to override a SPI method, like Mozilla and Chrome do. I couldn't find any other way to achieve it. As for whether it would be considered as Private API usage, I've already asked this question on macosxport-dev mailing list, see 4*. The answer was that I need to submit private JDK build to the App Store and see if it gets accepted. I'l do do it if reviewers agree with my fix. I gave this fix limited testing by running a number of regression tests and Netbeans, and haven't found any issues with it. Bug: http://bugs.sun.com/view_bug.do?bug_id=8020209 Webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.00/ 1. http://bugs.sun.com/view_bug.do?bug_id=7131196 2. http://bugs.sun.com/view_bug.do?bug_id=7142565 3. http://bugs.sun.com/view_bug.do?bug_id=7160951 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-September/004849.html Thanks, Leonid. From anthony.petrov at oracle.com Mon Sep 9 12:58:33 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 09 Sep 2013 23:58:33 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" In-Reply-To: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> References: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> Message-ID: <522E2869.5050201@oracle.com> Hi Leonid, This should be reviewed on awt-dev at . The macosx-port project has reached its goal long time ago, so the macosx-port-dev@ mailing list is pretty useless currently. As for the fix itself, even though I prefer to avoid using private APIs usually, given that both Chrome and Mozilla do that, I think it's OK in this case. Besides, the code looks a lot simpler and clearer now. So the fix looks good to me. BTW, can a test be written to cover all the mentioned issues so that we could catch any problems later (e.g., in case OS X stops supporting the SPI, or we break our own code ourselves). -- best regards, Anthony On 09/09/2013 03:20 PM, Leonid Romanov wrote: > Hello, > This is a bug with a long history. It all started with 1* followed by 2*. What looked like a perfectly fine approach back then has caused us a number of problems ever since, like 3* and all the other similar menu related issues that followed. JDK-8020209 is the latest in the series. What happens in JDK-8020209 is that Cocoa calls -performKeyEquivalent twice: first for "Cmd =" followed by the call for "Cmd +". > If you look at all these bugs, it will become evident that the crux of the problem is that we use -performKeyEquivalent to intercept key events that don't go through -keyDown, so this patch is an attempt to fix it. In order to make these events to go through -keyDown, I have to override a SPI method, like Mozilla and Chrome do. I couldn't find any other way to achieve it. As for whether it would be considered as Private API usage, I've already asked this question on macosxport-dev mailing list, see 4*. The answer was that I need to submit private JDK build to the App Store and see if it gets accepted. I'l do do it if reviewers agree with my fix. > I gave this fix limited testing by running a number of regression tests and Netbeans, and haven't found any issues with it. > > Bug: http://bugs.sun.com/view_bug.do?bug_id=8020209 > Webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.00/ > > 1. http://bugs.sun.com/view_bug.do?bug_id=7131196 > 2. http://bugs.sun.com/view_bug.do?bug_id=7142565 > 3. http://bugs.sun.com/view_bug.do?bug_id=7160951 > 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-September/004849.html > > > Thanks, > Leonid. > > From leonid.romanov at oracle.com Tue Sep 10 08:56:43 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Tue, 10 Sep 2013 19:56:43 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" In-Reply-To: <522E2869.5050201@oracle.com> References: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> <522E2869.5050201@oracle.com> Message-ID: <46480B8C-90FF-4C27-A459-6DFD6FA79F5A@oracle.com> Adding awt-dev to CC. I've added a regression test. It should fire if Apple ever decide to remove or alter the SPI I use. Btw, I've tested the fix on 10.9 and it works fine there. http://cr.openjdk.java.net/~leonidr/8020209/webrev.01/ On Sep 9, 2013, at 11:58 PM, Anthony Petrov wrote: > Hi Leonid, > > This should be reviewed on awt-dev at . The macosx-port project has reached its goal long time ago, so the macosx-port-dev@ mailing list is pretty useless currently. > > As for the fix itself, even though I prefer to avoid using private APIs usually, given that both Chrome and Mozilla do that, I think it's OK in this case. Besides, the code looks a lot simpler and clearer now. So the fix looks good to me. > > BTW, can a test be written to cover all the mentioned issues so that we could catch any problems later (e.g., in case OS X stops supporting the SPI, or we break our own code ourselves). > > -- > best regards, > Anthony > > On 09/09/2013 03:20 PM, Leonid Romanov wrote: >> Hello, >> This is a bug with a long history. It all started with 1* followed by 2*. What looked like a perfectly fine approach back then has caused us a number of problems ever since, like 3* and all the other similar menu related issues that followed. JDK-8020209 is the latest in the series. What happens in JDK-8020209 is that Cocoa calls -performKeyEquivalent twice: first for "Cmd =" followed by the call for "Cmd +". >> If you look at all these bugs, it will become evident that the crux of the problem is that we use -performKeyEquivalent to intercept key events that don't go through -keyDown, so this patch is an attempt to fix it. In order to make these events to go through -keyDown, I have to override a SPI method, like Mozilla and Chrome do. I couldn't find any other way to achieve it. As for whether it would be considered as Private API usage, I've already asked this question on macosxport-dev mailing list, see 4*. The answer was that I need to submit private JDK build to the App Store and see if it gets accepted. I'l do do it if reviewers agree with my fix. >> I gave this fix limited testing by running a number of regression tests and Netbeans, and haven't found any issues with it. >> >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020209 >> Webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.00/ >> >> 1. http://bugs.sun.com/view_bug.do?bug_id=7131196 >> 2. http://bugs.sun.com/view_bug.do?bug_id=7142565 >> 3. http://bugs.sun.com/view_bug.do?bug_id=7160951 >> 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-September/004849.html >> >> >> Thanks, >> Leonid. >> >> From anthony.petrov at oracle.com Tue Sep 10 12:56:39 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Tue, 10 Sep 2013 23:56:39 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" In-Reply-To: <46480B8C-90FF-4C27-A459-6DFD6FA79F5A@oracle.com> References: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> <522E2869.5050201@oracle.com> <46480B8C-90FF-4C27-A459-6DFD6FA79F5A@oracle.com> Message-ID: <522F7977.3010108@oracle.com> Looks great. Thank you. -- best regards, Anthony On 09/10/2013 07:56 PM, Leonid Romanov wrote: > Adding awt-dev to CC. > > I've added a regression test. It should fire if Apple ever decide to remove or alter the SPI I use. Btw, I've tested the fix on 10.9 and it works fine there. > > http://cr.openjdk.java.net/~leonidr/8020209/webrev.01/ > > On Sep 9, 2013, at 11:58 PM, Anthony Petrov wrote: > >> Hi Leonid, >> >> This should be reviewed on awt-dev at . The macosx-port project has reached its goal long time ago, so the macosx-port-dev@ mailing list is pretty useless currently. >> >> As for the fix itself, even though I prefer to avoid using private APIs usually, given that both Chrome and Mozilla do that, I think it's OK in this case. Besides, the code looks a lot simpler and clearer now. So the fix looks good to me. >> >> BTW, can a test be written to cover all the mentioned issues so that we could catch any problems later (e.g., in case OS X stops supporting the SPI, or we break our own code ourselves). >> >> -- >> best regards, >> Anthony >> >> On 09/09/2013 03:20 PM, Leonid Romanov wrote: >>> Hello, >>> This is a bug with a long history. It all started with 1* followed by 2*. What looked like a perfectly fine approach back then has caused us a number of problems ever since, like 3* and all the other similar menu related issues that followed. JDK-8020209 is the latest in the series. What happens in JDK-8020209 is that Cocoa calls -performKeyEquivalent twice: first for "Cmd =" followed by the call for "Cmd +". >>> If you look at all these bugs, it will become evident that the crux of the problem is that we use -performKeyEquivalent to intercept key events that don't go through -keyDown, so this patch is an attempt to fix it. In order to make these events to go through -keyDown, I have to override a SPI method, like Mozilla and Chrome do. I couldn't find any other way to achieve it. As for whether it would be considered as Private API usage, I've already asked this question on macosxport-dev mailing list, see 4*. The answer was that I need to submit private JDK build to the App Store and see if it gets accepted. I'l do do it if reviewers agree with my fix. >>> I gave this fix limited testing by running a number of regression tests and Netbeans, and haven't found any issues with it. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020209 >>> Webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.00/ >>> >>> 1. http://bugs.sun.com/view_bug.do?bug_id=7131196 >>> 2. http://bugs.sun.com/view_bug.do?bug_id=7142565 >>> 3. http://bugs.sun.com/view_bug.do?bug_id=7160951 >>> 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-September/004849.html >>> >>> >>> Thanks, >>> Leonid. >>> >>> > From david.dehaven at oracle.com Tue Sep 10 13:06:52 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 10 Sep 2013 13:06:52 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: This isn't every other platform, this is Mac OS X and all the baggage that goes along with it! :) What do you actually need access to user.home for? Do you have empirical evidence that this will break your application? The whole point of sandboxing is you no longer have direct access to the entire system. The app must play inside it's sandbox, period, end of story. Gone are the days of unrestricted access to the filesystem, that's the whole point of sandboxing! This is all pretty well outlined in the "Sandboxing Your App" documentation on ADC. Powerbox is there to solve your problem of opening user documents (with the right entitlements) and there are mechanisms in place to allow opening related files (with the users permission of course). Even a sandboxed application can show the user the contents of his various folders in a file open dialog. This all happens regardless of whether NSHomeDirectory returns /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp -DrD- > If you're saying that NSHomeDirectory is the correct behaviour for the Java user.home property, then I have to disagree. On every other platform, including non-sandboxed Mac, user.home is the actual user's home directory (i.e. /home/ or /Users/ or C:\Users\). Setting user.home to the *application's* home directory (which is what NSHomeDirectory returns in a sandboxed environment) would seem to me to break the definition of the user.home property. > > On a mac, in a sandboxed and non-sandboxed environment, I would expect user.home to be NSHomeDirectoryForUser. A sandboxed Java app definitely needs to know about the app's Container directory (and even whether it's actually being run sandboxed or not), but redefining user.home doesn't seem like the right solution. Having AppBundler (or even the JRE) provide that information via special properties feels better from my developer's perspective. > > Nick > > > > On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven wrote: > > >> As someone with a Java app in the Mac App Store (MAS), I would like to vote against this change. > >> > >> It is still important to know the user's actual home directory (/Users/) even if the app is running in the sandbox. Using the entitlement, com.apple.security.files.user-selected.read-write, we can still write to user selected directories (such as ~/Documents). So changing the user.home property to point to somewhere in the app's Container would make it more difficult to get the actual home directory and thus, other directories that the end-user is familiar with. I also think this change would lead to more developer confusion and make application code more complicated. > >> > >> I don't know all what the user.home property is used for in the JDK itself, but concerns about the MAS sandbox would be, IMHO, better handled using special Mac/MAS only properties, such as those setup by infinitekind's Appbundler fork on bitbucket: https://bitbucket.org/infinitekind/appbundler > >> > >> Nick > > I'm sure Brent wants to do the right thing here and maybe this needs some input from the Apple or other Mac-savvy folks as to whether sandboxed apps are really supposed to know about the actual user's home directory. > > > > FWIW, the original recommendaiton to switch to NSHomeDirectory came from Scott Kovatch when he was working on Application Bundler. It's very possible that things have changed since then. > > > I haven't had a chance to look at the changes yet, so this may be a bit premature... > > > Using NSHomeDirectory is the CORRECT behavior, whether the app is sandboxed or not (that extends to ALL apps, not just Java based). > > If the application needs to access Documents, Music, Movies, etc then those entitlements need to be added. Additionally, even if sandboxed an application can open documents in any folder the user has access to as long as the standard file chooser is used (which I believe we already do), the app will be granted (indirect) access to the selected file(s). > > -DrD- > > From david.dehaven at oracle.com Tue Sep 10 13:32:05 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 10 Sep 2013 13:32:05 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> Message-ID: <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> > This isn't every other platform, this is Mac OS X and all the baggage that goes along with it! :) > > What do you actually need access to user.home for? Do you have empirical evidence that this will break your application? > > The whole point of sandboxing is you no longer have direct access to the entire system. The app must play inside it's sandbox, period, end of story. Gone are the days of unrestricted access to the filesystem, that's the whole point of sandboxing! This is all pretty well outlined in the "Sandboxing Your App" documentation on ADC. > > Powerbox is there to solve your problem of opening user documents (with the right entitlements) and there are mechanisms in place to allow opening related files (with the users permission of course). Even a sandboxed application can show the user the contents of his various folders in a file open dialog. This all happens regardless of whether NSHomeDirectory returns /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp That should have been: /Users/JoeBob/Library/Containers/com.blah.someapp/Data Which, btw, is a shadow of the users home directory... including symlinks to various folders contained therein. -DrD- From nick at transparentech.com Tue Sep 10 14:21:36 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Tue, 10 Sep 2013 23:21:36 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> Message-ID: I use user.home to do things like: String userHomePath = System.getProperty("user.home"**); myFileDialog.setDirectory(**userHomePath + "/Documents"); In my app, the user selects where he wants to export individual files, such as CSVs and PDFs. These are files he'll use outside of my app. If user.home points to the app's sandbox Container, it will break this usage. Opening a file dialog to /Users/Bob/Library/Containers/my.app/Data/Documents will definitely confuse the user and if they save a file there, they will never be able to find it later from outside of my app. Yes, I understand the whole sandboxing concept. I'm not asking for unrestricted access to the file system. I use the "com.apple. security.files.user-selected.read-write" entitlement so that the user can select where he wants to save files, and I want to present him with a standard, well-known, default location for that (like ~/Documents). If user.home doesn't point to the user's actual home folder (i.e. NSHomeDirectoryForUser), it makes creating a standard, well-known location path (like ~/Documents) much more difficult. (And IMHO, it breaks the definition of the user.home property: "User home directory", not "App home directory".) Nick On Tue, Sep 10, 2013 at 10:32 PM, David DeHaven wrote: > > > This isn't every other platform, this is Mac OS X and all the baggage > that goes along with it! :) > > > > What do you actually need access to user.home for? Do you have empirical > evidence that this will break your application? > > > > The whole point of sandboxing is you no longer have direct access to the > entire system. The app must play inside it's sandbox, period, end of story. > Gone are the days of unrestricted access to the filesystem, that's the > whole point of sandboxing! This is all pretty well outlined in the > "Sandboxing Your App" documentation on ADC. > > > > Powerbox is there to solve your problem of opening user documents (with > the right entitlements) and there are mechanisms in place to allow opening > related files (with the users permission of course). Even a sandboxed > application can show the user the contents of his various folders in a file > open dialog. This all happens regardless of whether NSHomeDirectory returns > /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp > > > That should have been: > /Users/JoeBob/Library/Containers/com.blah.someapp/Data > > Which, btw, is a shadow of the users home directory... including symlinks > to various folders contained therein. > > -DrD- > > > From david.dehaven at oracle.com Tue Sep 10 15:36:32 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 10 Sep 2013 15:36:32 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> Message-ID: > I use user.home to do things like: > > String userHomePath = System.getProperty("user.home"); > myFileDialog.setDirectory(userHomePath + "/Documents"); This will continue to work fine. Like I said, user.home is the Data directory inside the app container which is a shadow of the users home folder, complete with symlinks to common user directories (such as Documents, Movies, Music, etc..). Sandboxd and powerbox manage all the translations behind the scene. > In my app, the user selects where he wants to export individual files, such as CSVs and PDFs. These are files he'll use outside of my app. > > If user.home points to the app's sandbox Container, it will break this usage. Opening a file dialog to /Users/Bob/Library/Containers/my.app/Data/Documents will definitely confuse the user and if they save a file there, they will never be able to find it later from outside of my app. The user won't know the difference, all they'll see is ~/Documents as provided by powerbox. Fun fact: The reason powerbox isn't hackable is it runs in a separate process... > Yes, I understand the whole sandboxing concept. I'm not asking for unrestricted access to the file system. I use the "com.apple.security.files.user-selected.read-write" entitlement so that the user can select where he wants to save files, and I want to present him with a standard, well-known, default location for that (like ~/Documents). > > If user.home doesn't point to the user's actual home folder (i.e. NSHomeDirectoryForUser), it makes creating a standard, well-known location path (like ~/Documents) much more difficult. (And IMHO, it breaks the definition of the user.home property: "User home directory", not "App home directory".) Powerbox solves exactly that problem... and yes, yes it is users home folder, from the perspective of a sandboxed application! Here's some code to prove it actually works since you don't seem to believe me: { @autorelease { NSOpenPanel *panel = [NSOpenPanel openPanel]; panel.allowsMultipleSelection = NO; panel.canChooseDirectories = NO; NSString *home = NSHomeDirectory(); NSString *docs = [home stringByAppendingPathComponent:@"Downloads"]; NSLog(@"home: %@", home); NSLog(@"docs: %@", docs); [panel setDirectoryURL:[NSURL fileURLWithPath:docs]]; [panel beginWithCompletionHandler:^(NSInteger result) { NSLog(@"panel result: %ld", result); if (result == NSFileHandlingPanelOKButton) { NSLog(@"panel selected file: %@", [[panel URLs] objectAtIndex:0]); } }]; } } Example run: 2013-09-10 15:30:52.630 BlahText[11480:303] home: /Users/daved/Library/Containers/com.blah.SomeApp/Data 2013-09-10 15:30:52.631 BlahText[11480:303] docs: /Users/daved/Library/Containers/com.blah.SomeApp/Data/Documents 2013-09-10 15:30:59.180 BlahText[11480:303] panel result: 1 2013-09-10 15:30:59.180 BlahText[11480:303] panel selected file: file://localhost/Users/daved/Documents/Some%20Document.txt And the open panel opens displaying the contents of my Documents folder, the user will never see the app container path unless you explicitly report it to them. -DrD- From brent.christian at oracle.com Tue Sep 10 17:27:18 2013 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 10 Sep 2013 17:27:18 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> Message-ID: <522FB8E6.4020209@oracle.com> Adding a little to what Dave said, based on my understanding... On 9/10/13 3:36 PM, David DeHaven wrote: > Nicholas Rahn wrote: > >> In my app, the user selects where he wants to export individual >> files, such as CSVs and PDFs. These are files he'll use outside of >> my app. >> >> If user.home points to the app's sandbox Container, it will break >> this usage. Opening a file dialog to >> /Users/Bob/Library/Containers/my.app/Data/Documents will definitely >> confuse the user and if they save a file there, they will never be >> able to find it later from outside of my app. > > The user won't know the difference, all they'll see is ~/Documents as > provided by powerbox. Note that PowerBox+NSOpenPanel recognize the Container path, and automagically take the user to their *actual* $HOME, Documents, etc directories. With this change, then, telling a native FileDialog to open user.home (or user.home/Documents, etc), will (still) show the user their real $HOME (or $HOME/Documents, etc) directory, whether sandboxed (user.home is the app Container, redirected by PowerBox to $HOME) or not (user.home=$HOME). The selected file returned from the FileDialog will point to a location within $HOME, and because of the *.files.user-selected.* entitlement, the app will now have access to it. >> Yes, I understand the whole sandboxing concept. I'm not asking for >> unrestricted access to the file system. I use the >> "com.apple.security.files.user-selected.read-write" entitlement so >> that the user can select where he wants to save files, and I want >> to present him with a standard, well-known, default location for >> that (like ~/Documents). >> >> If user.home doesn't point to the user's actual home folder (i.e. >> NSHomeDirectoryForUser), it makes creating a standard, well-known >> location path (like ~/Documents) much more difficult. BTW, NSHomeDirectoryForUser() for the current user returns the same sandboxed value as NSHomeDirectory(). Without this change, user.home is obtained using the POSIX getpwuid() call - really not the Apple-recommended way for dealing with the sandbox. > Powerbox solves exactly that problem... and yes, yes it is users home > folder, from the perspective of a sandboxed application! > > ... > >the user will never see the app container path unless you > explicitly report it to them. ...though it's really not mean to be presented to the user (and I haven't been able to convince FileDialog to take me to it). The Container directory is meant only for files used by the app itself. From [1]: "The container is in a hidden location, and so users do not interact with it directly. Specifically, the container is not for user documents. It is for files that your app uses, along with databases, caches, and other app-specific data" The suggested change to the value of user.home means that it can be used by apps to write their own private data files AND (thanks to the PowerBox magic) point a user to their $HOME within a native file dialog, AND it will work inside or outside the App Sandbox. As it is now, apps needing to write app-specific data would need to special-case for the App Sandbox and go find the Container directory, since $HOME is not accessible (and only becomes accessible if the user interacts with a FileDialog). Thanks, -Brent [1] https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW15 From Sergey.Bylokhov at oracle.com Wed Sep 11 02:19:56 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Sep 2013 13:19:56 +0400 Subject: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" In-Reply-To: <46480B8C-90FF-4C27-A459-6DFD6FA79F5A@oracle.com> References: <72E40B7E-B037-40B6-9A7D-5E0C8345E910@oracle.com> <522E2869.5050201@oracle.com> <46480B8C-90FF-4C27-A459-6DFD6FA79F5A@oracle.com> Message-ID: <523035BC.1080100@oracle.com> Fix looks good. On 10.09.2013 19:56, Leonid Romanov wrote: > Adding awt-dev to CC. > > I've added a regression test. It should fire if Apple ever decide to remove or alter the SPI I use. Btw, I've tested the fix on 10.9 and it works fine there. > > http://cr.openjdk.java.net/~leonidr/8020209/webrev.01/ > > On Sep 9, 2013, at 11:58 PM, Anthony Petrov wrote: > >> Hi Leonid, >> >> This should be reviewed on awt-dev at . The macosx-port project has reached its goal long time ago, so the macosx-port-dev@ mailing list is pretty useless currently. >> >> As for the fix itself, even though I prefer to avoid using private APIs usually, given that both Chrome and Mozilla do that, I think it's OK in this case. Besides, the code looks a lot simpler and clearer now. So the fix looks good to me. >> >> BTW, can a test be written to cover all the mentioned issues so that we could catch any problems later (e.g., in case OS X stops supporting the SPI, or we break our own code ourselves). >> >> -- >> best regards, >> Anthony >> >> On 09/09/2013 03:20 PM, Leonid Romanov wrote: >>> Hello, >>> This is a bug with a long history. It all started with 1* followed by 2*. What looked like a perfectly fine approach back then has caused us a number of problems ever since, like 3* and all the other similar menu related issues that followed. JDK-8020209 is the latest in the series. What happens in JDK-8020209 is that Cocoa calls -performKeyEquivalent twice: first for "Cmd =" followed by the call for "Cmd +". >>> If you look at all these bugs, it will become evident that the crux of the problem is that we use -performKeyEquivalent to intercept key events that don't go through -keyDown, so this patch is an attempt to fix it. In order to make these events to go through -keyDown, I have to override a SPI method, like Mozilla and Chrome do. I couldn't find any other way to achieve it. As for whether it would be considered as Private API usage, I've already asked this question on macosxport-dev mailing list, see 4*. The answer was that I need to submit private JDK build to the App Store and see if it gets accepted. I'l do do it if reviewers agree with my fix. >>> I gave this fix limited testing by running a number of regression tests and Netbeans, and haven't found any issues with it. >>> >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8020209 >>> Webrev: http://cr.openjdk.java.net/~leonidr/8020209/webrev.00/ >>> >>> 1. http://bugs.sun.com/view_bug.do?bug_id=7131196 >>> 2. http://bugs.sun.com/view_bug.do?bug_id=7142565 >>> 3. http://bugs.sun.com/view_bug.do?bug_id=7160951 >>> 4. http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-September/004849.html >>> >>> >>> Thanks, >>> Leonid. >>> >>> -- Best regards, Sergey. From leonid.romanov at oracle.com Wed Sep 11 02:24:32 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Sep 2013 13:24:32 +0400 Subject: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Message-ID: <0470AF9C-218D-4022-89C3-D37AC1DEB7E0@oracle.com> Hello, Please review a fix for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol. bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 webrev: http://cr.openjdk.java.net/~leonidr/7129133/webrev.00/ Thanks, Leonid. From alexandr.scherbatiy at oracle.com Wed Sep 11 04:17:10 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Sep 2013 15:17:10 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Message-ID: <52305136.9040408@oracle.com> Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 The fix check if an NSWindow is in zoomed state before maximize it. Thanks, Alexandr. From leonid.romanov at oracle.com Wed Sep 11 04:40:13 2013 From: leonid.romanov at oracle.com (Leonid Romanov) Date: Wed, 11 Sep 2013 15:40:13 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52305136.9040408@oracle.com> References: <52305136.9040408@oracle.com> Message-ID: <5230569D.5080205@oracle.com> Hi, Looks good to me. On 9/11/2013 15:17, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 > webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 > > The fix check if an NSWindow is in zoomed state before maximize it. > > Thanks, > Alexandr. > From Sergey.Bylokhov at oracle.com Wed Sep 11 04:47:43 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Sep 2013 15:47:43 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52305136.9040408@oracle.com> References: <52305136.9040408@oracle.com> Message-ID: <5230585F.600@oracle.com> Hi, Alexander. Looks like the main issue is that CPW.zoomed and actual state of the NSWindow is out of sync. Does unmaximize works after the fix? I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. On 11.09.2013 15:17, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 > webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 > > The fix check if an NSWindow is in zoomed state before maximize it. > > Thanks, > Alexandr. > -- Best regards, Sergey. From nick at transparentech.com Wed Sep 11 06:50:08 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Wed, 11 Sep 2013 15:50:08 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <522FB8E6.4020209@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> Message-ID: In my app, I have an export dialog where the user can select the file to export as well as choose some other export options. In that dialog, after the user has selected the file to export (via the file selection dialog), I display the full path to the file that was returned from the file selection Dialog. So, if I understand you correctly (sorry, I haven't had time to verify this myself), with this change, passing in "user.home/Documents" to the file dialog, the user will see "~/Documents" in the file dialog, but the full Container path will be returned as the selected file. So in my export dialog, the user would see the full Container path, even though the file selection dialog had shown a normal ~/Documents path? Additionally what's not clear is (again, sorry, I haven't had time to verify this myself), if I do export the file to the Documents directory under the Container path, where does the file actually get saved? In /Users/nick/Documents or in /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the Container's Documents folder, for other applications (Finder, Excel, Preview, etc) will it be visible in /Users/nick/Documents ? @Brent - you wrote: "As it is now, apps needing to write app-specific data would need to special-case for the App Sandbox and go find the Container directory, since $HOME is not accessible (and only becomes accessible if the user interacts with a FileDialog)." Well, I already had to special case where I write app-specific data for each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that is really cross-platform is going to have some platform specific code and platform specific jvm-launching/packaging, if they want to do things the recommended way for that platform. A sandboxed Mac version was just another special case. For that, I use the AppBundler fork to launch the JVM and set some MAS specific properties so that I know that I'm running in the Mac sandbox and where the Container directory is. Then the right platform-specific initialization code in my app can be used to build the app-specific data in the right place. Thanks, Nick On Wed, Sep 11, 2013 at 2:27 AM, Brent Christian wrote: > Adding a little to what Dave said, based on my understanding... > > On 9/10/13 3:36 PM, David DeHaven wrote: > > > Nicholas Rahn wrote: > >> >> In my app, the user selects where he wants to export individual >>> files, such as CSVs and PDFs. These are files he'll use outside of >>> my app. >>> >>> If user.home points to the app's sandbox Container, it will break >>> this usage. Opening a file dialog to >>> /Users/Bob/Library/Containers/**my.app/Data/Documents will definitely >>> confuse the user and if they save a file there, they will never be >>> able to find it later from outside of my app. >>> >> >> The user won't know the difference, all they'll see is ~/Documents as >> provided by powerbox. >> > > Note that PowerBox+NSOpenPanel recognize the Container path, and > automagically take the user to their *actual* $HOME, Documents, etc > directories. > > With this change, then, telling a native FileDialog to open user.home (or > user.home/Documents, etc), will (still) show the user their real $HOME (or > $HOME/Documents, etc) directory, whether sandboxed (user.home is the app > Container, redirected by PowerBox to $HOME) or not (user.home=$HOME). > > The selected file returned from the FileDialog will point to a location > within $HOME, and because of the *.files.user-selected.* entitlement, the > app will now have access to it. > > > Yes, I understand the whole sandboxing concept. I'm not asking for >>> unrestricted access to the file system. I use the >>> "com.apple.security.files.**user-selected.read-write" entitlement so >>> that the user can select where he wants to save files, and I want >>> to present him with a standard, well-known, default location for >>> that (like ~/Documents). >>> >>> If user.home doesn't point to the user's actual home folder (i.e. >>> NSHomeDirectoryForUser), it makes creating a standard, well-known >>> location path (like ~/Documents) much more difficult. >>> >> > BTW, NSHomeDirectoryForUser() for the current user returns the same > sandboxed value as NSHomeDirectory(). > > Without this change, user.home is obtained using the POSIX getpwuid() call > - really not the Apple-recommended way for dealing with the sandbox. > > > Powerbox solves exactly that problem... and yes, yes it is users home >> folder, from the perspective of a sandboxed application! >> > > > > ... > > > > >> the user will never see the app container path unless you >> explicitly report it to them. >> > > ...though it's really not mean to be presented to the user (and I haven't > been able to convince FileDialog to take me to it). The Container > directory is meant only for files used by the app itself. From [1]: > > "The container is in a hidden location, and so users do not interact with > it directly. Specifically, the container is not for user documents. It is > for files that your app uses, along with databases, caches, and other > app-specific data" > > > The suggested change to the value of user.home means that it can be used > by apps to write their own private data files AND (thanks to the PowerBox > magic) point a user to their $HOME within a native file dialog, AND it will > work inside or outside the App Sandbox. > > As it is now, apps needing to write app-specific data would need to > special-case for the App Sandbox and go find the Container directory, since > $HOME is not accessible (and only becomes accessible if the user interacts > with a FileDialog). > > Thanks, > -Brent > > [1] https://developer.apple.com/**library/mac/documentation/** > security/conceptual/**AppSandboxDesignGuide/**AppSandboxInDepth/** > AppSandboxInDepth.html#//**apple_ref/doc/uid/TP40011183-**CH3-SW15 > From david.dehaven at oracle.com Wed Sep 11 09:39:34 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Sep 2013 09:39:34 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> Message-ID: > In my app, I have an export dialog where the user can select the file to export as well as choose some other export options. In that dialog, after the user has selected the file to export (via the file selection dialog), I display the full path to the file that was returned from the file selection Dialog. > > So, if I understand you correctly (sorry, I haven't had time to verify this myself), with this change, passing in "user.home/Documents" to the file dialog, the user will see "~/Documents" in the file dialog, but the full Container path will be returned as the selected file. So in my export dialog, the user would see the full Container path, even though the file selection dialog had shown a normal ~/Documents path? If you're using FileDialog (or some variant that eventually boils down to NSSavePanel) then your app will continue to function properly. If you're using a custom dialog then you'll need to switch to FileDialog (or variant...) since NSSavePanel is what triggers powerbox to do it's thing, if NSSavePanel is not invoked to choose the exported file then your app will never be granted permission to write to the file (unless you incant some other, more complicated, voodoo magic). The bottom line is, if what you have now allows you to write to ~/Documents and you're sandboxed then this change should not affect your application at all, except maybe in the UI if you're displaying that path to the user. The user won't notice the difference otherwise. > Additionally what's not clear is (again, sorry, I haven't had time to verify this myself), if I do export the file to the Documents directory under the Container path, where does the file actually get saved? In /Users/nick/Documents or in /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the Container's Documents folder, for other applications (Finder, Excel, Preview, etc) will it be visible in /Users/nick/Documents ? If you look in the app container you'll see that the Data directory returned by NSHomeDirectory() is set up with symlinks back to the users home directory, so when you access files in those directories you're accessing the correct files. IOW, ~/Library/Containers/com.blah.someapp/Data/Documents is the same as ~/Documents, the system does all this for you when the app container is created. > @Brent - you wrote: > "As it is now, apps needing to write app-specific data would need to special-case for the App Sandbox and go find the Container directory, since $HOME is not accessible (and only becomes accessible if the user interacts with a FileDialog)." > > Well, I already had to special case where I write app-specific data for each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that is really cross-platform is going to have some platform specific code and platform specific jvm-launching/packaging, if they want to do things the recommended way for that platform. A sandboxed Mac version was just another special case. For that, I use the AppBundler fork to launch the JVM and set some MAS specific properties so that I know that I'm running in the Mac sandbox and where the Container directory is. Then the right platform-specific initialization code in my app can be used to build the app-specific data in the right place. That's the unfortunately truth of modern (secure) applications, each platform has it's own way of doing things. Have you tried Windows 8 yet? Changes like what Brent is proposing is helping to keep Java consistent with the ever evolving app model, which is ultimately a good thing. -DrD- From swilson at storyrock.com Wed Sep 11 10:36:01 2013 From: swilson at storyrock.com (Steven Wilson) Date: Wed, 11 Sep 2013 11:36:01 -0600 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: Message-ID: <941712B7-CEF4-4AFF-A97B-BA5795853C11@storyrock.com> In the versions of Mac OS X that I'm looking at (Lion and Mtn Lion) the Documents folder inside the sandbox is NOT a symlink. Desktop, Downloads, Movies, Music and Pictures ARE all symlinks, but not Documents, so "~/Library/Containers/com.blah.someapp/Data/Documents" is not the same as "~/Documents". Someone correct me if I'm wrong but that's what I'm seeing. Steve Wilson On Sep 11, 2013, at 10:39 AM, macosx-port-dev-request at openjdk.java.net wrote: >> In my app, I have an export dialog where the user can select the >> file to export as well as choose some other export options. In that >> dialog, after the user has selected the file to export (via the >> file selection dialog), I display the full path to the file that >> was returned from the file selection Dialog. >> >> So, if I understand you correctly (sorry, I haven't had time to >> verify this myself), with this change, passing in "user.home/ >> Documents" to the file dialog, the user will see "~/Documents" in >> the file dialog, but the full Container path will be returned as >> the selected file. So in my export dialog, the user would see the >> full Container path, even though the file selection dialog had >> shown a normal ~/Documents path? > > If you're using FileDialog (or some variant that eventually boils > down to NSSavePanel) then your app will continue to function > properly. If you're using a custom dialog then you'll need to switch > to FileDialog (or variant...) since NSSavePanel is what triggers > powerbox to do it's thing, if NSSavePanel is not invoked to choose > the exported file then your app will never be granted permission to > write to the file (unless you incant some other, more complicated, > voodoo magic). > > The bottom line is, if what you have now allows you to write to ~/ > Documents and you're sandboxed then this change should not affect > your application at all, except maybe in the UI if you're displaying > that path to the user. The user won't notice the difference otherwise. > > >> Additionally what's not clear is (again, sorry, I haven't had time >> to verify this myself), if I do export the file to the Documents >> directory under the Container path, where does the file actually >> get saved? In /Users/nick/Documents or in /Users/nick/Library/ >> Container/my.app/Data/Documents? If it saves it to the Container's >> Documents folder, for other applications (Finder, Excel, Preview, >> etc) will it be visible in /Users/nick/Documents ? > > If you look in the app container you'll see that the Data directory > returned by NSHomeDirectory() is set up with symlinks back to the > users home directory, so when you access files in those directories > you're accessing the correct files. IOW, ~/Library/Containers/ > com.blah.someapp/Data/Documents is the same as ~/Documents, the > system does all this for you when the app container is created. > > >> @Brent - you wrote: >> "As it is now, apps needing to write app-specific data would need >> to special-case for the App Sandbox and go find the Container >> directory, since $HOME is not accessible (and only becomes >> accessible if the user interacts with a FileDialog)." >> >> Well, I already had to special case where I write app-specific data >> for each of the 3 platforms I support (Mac, Windows & Linux). Any >> Java app that is really cross-platform is going to have some >> platform specific code and platform specific jvm-launching/ >> packaging, if they want to do things the recommended way for that >> platform. A sandboxed Mac version was just another special case. >> For that, I use the AppBundler fork to launch the JVM and set some >> MAS specific properties so that I know that I'm running in the Mac >> sandbox and where the Container directory is. Then the right >> platform-specific initialization code in my app can be used to >> build the app-specific data in the right place. > > That's the unfortunately truth of modern (secure) applications, each > platform has it's own way of doing things. Have you tried Windows 8 > yet? > > Changes like what Brent is proposing is helping to keep Java > consistent with the ever evolving app model, which is ultimately a > good thing. > > -DrD- From nick at transparentech.com Wed Sep 11 11:09:56 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Wed, 11 Sep 2013 20:09:56 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> Message-ID: > > In my app, I have an export dialog where the user can select the file to > export as well as choose some other export options. In that dialog, after > the user has selected the file to export (via the file selection dialog), I > display the full path to the file that was returned from the file selection > Dialog. > > > > So, if I understand you correctly (sorry, I haven't had time to verify > this myself), with this change, passing in "user.home/Documents" to the > file dialog, the user will see "~/Documents" in the file dialog, but the > full Container path will be returned as the selected file. So in my export > dialog, the user would see the full Container path, even though the file > selection dialog had shown a normal ~/Documents path? > > If you're using FileDialog (or some variant that eventually boils down to > NSSavePanel) then your app will continue to function properly. If you're > using a custom dialog then you'll need to switch to FileDialog (or > variant...) since NSSavePanel is what triggers powerbox to do it's thing, > if NSSavePanel is not invoked to choose the exported file then your app > will never be granted permission to write to the file (unless you incant > some other, more complicated, voodoo magic). > > The bottom line is, if what you have now allows you to write to > ~/Documents and you're sandboxed then this change should not affect your > application at all, except maybe in the UI if you're displaying that path > to the user. The user won't notice the difference otherwise. > > My users *will* notice because I display this path in the export dialog, along with the other export options they can use. Side note: I'm using SWT and it boils down to the NSOpenPanel and NSSavePanel. > > Additionally what's not clear is (again, sorry, I haven't had time to > verify this myself), if I do export the file to the Documents directory > under the Container path, where does the file actually get saved? In > /Users/nick/Documents or in > /Users/nick/Library/Container/my.app/Data/Documents? If it saves it to the > Container's Documents folder, for other applications (Finder, Excel, > Preview, etc) will it be visible in /Users/nick/Documents ? > > If you look in the app container you'll see that the Data directory > returned by NSHomeDirectory() is set up with symlinks back to the users > home directory, so when you access files in those directories you're > accessing the correct files. IOW, > ~/Library/Containers/com.blah.someapp/Data/Documents is the same as > ~/Documents, the system does all this for you when the app container is > created. > > Actually, the Documents directory in the Container is NOT a symlink. It is an actual directory. So the 2 key questions are: 1. Is there a way to convert from /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to ~/Documents/somefile.csv to display in the UI for the user? 2. If the file gets saved to /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can other applications (such as Excel) access the file from ~/Documents/somefile.csv ? > > @Brent - you wrote: > > "As it is now, apps needing to write app-specific data would need to > special-case for the App Sandbox and go find the Container directory, since > $HOME is not accessible (and only becomes accessible if the user interacts > with a FileDialog)." > > > > Well, I already had to special case where I write app-specific data for > each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that > is really cross-platform is going to have some platform specific code and > platform specific jvm-launching/packaging, if they want to do things the > recommended way for that platform. A sandboxed Mac version was just another > special case. For that, I use the AppBundler fork to launch the JVM and > set some MAS specific properties so that I know that I'm running in the Mac > sandbox and where the Container directory is. Then the right > platform-specific initialization code in my app can be used to build the > app-specific data in the right place. > > That's the unfortunately truth of modern (secure) applications, each > platform has it's own way of doing things. Have you tried Windows 8 yet? > > Changes like what Brent is proposing is helping to keep Java consistent > with the ever evolving app model, which is ultimately a good thing. > > Platform specific code for any Java desktop app is inevitable. What bothers me about this proposed change is that you're taking away a useful property (the user's $HOME) and replacing it with something that, to me, is best done in an app's platform specific code, not in the JDK's. And I still need to know the user's $HOME, since the answers to my 2 questions above are probably 'no', so I'll have to add more to my app's Mac sandbox-specific code to get it. Windows 8: I do have a few people using my software on W8, but I have not done anything specific for it. That is to say, I do the same platform specific stuff as I do on W7. Nick From david.dehaven at oracle.com Wed Sep 11 11:51:06 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Sep 2013 11:51:06 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <941712B7-CEF4-4AFF-A97B-BA5795853C11@storyrock.com> References: <941712B7-CEF4-4AFF-A97B-BA5795853C11@storyrock.com> Message-ID: <6FDDF604-5090-4E37-BE75-0406735FA6D0@oracle.com> > In the versions of Mac OS X that I'm looking at (Lion and Mtn Lion) the Documents folder inside the sandbox is NOT a symlink. Desktop, Downloads, Movies, Music and Pictures ARE all symlinks, but not Documents, so "~/Library/Containers/com.blah.someapp/Data/Documents" is not the same as "~/Documents". Someone correct me if I'm wrong but that's what I'm seeing. You're correct, I missed that detail :) NSOpenPanel/NSSavePanel both return URLs to the actual Documents folder, even if you pass ~/Library/Containers/com.blah.someapp/Data/Documents as the starting folder. -DrD- From brent.christian at oracle.com Wed Sep 11 15:07:17 2013 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 11 Sep 2013 15:07:17 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> Message-ID: <5230E995.3090609@oracle.com> On 9/11/13 11:09 AM, Nicholas Rahn wrote: > On David DeHaven wrote: > >> In my app, I have an export dialog where the user can select the >> file to export as well as choose some other export options. In >> that dialog, after the user has selected the file to export (via >> the file selection dialog), I display the full path to the file >> that was returned from the file selection Dialog. >> >> So, if I understand you correctly (sorry, I haven't had time to >> verify this myself), with this change, passing in >> "user.home/Documents" to the file dialog, the user will see >> "~/Documents" in the file dialog, but the full Container path will >> be returned as the selected file. The user will see ~/Documents, and a selected file in ~/Documents will have a full path into ~/Documents. The user is not meant to know anything about the sandbox container, and the file dialog enforces that. If you point it to the Container path, it takes you to ~ instead, and from then on you're working within ~. >> The bottom line is, if what you have now allows you to write to >> ~/Documents and you're sandboxed then this change should not >> affect your application at all, except maybe in the UI if you're >> displaying that path to the user. The user won't notice the >> difference otherwise. > > My users *will* notice because I display this path in the export dialog, > along with the other export options they can use. If the path displayed is coming from the selected file, then it will continue to show the correct path. > Side note: I'm using SWT and it boils down to the NSOpenPanel and > NSSavePanel. Yep, that should work fine. > Additionally what's not clear is (again, sorry, I haven't had time to > verify this myself), if I do export the file to the Documents > directory under the Container path, where does the file actually get > saved? In /Users/nick/Documents or in > /Users/nick/Library/Container/my.app/Data/Documents? A path selected by the user using a file dialog will not point into the Container; you'd have to go out of your way to do this. But if you did, say, write a file into /Users/nick/Library/Container/my.app/Data/Documents/ that's where it would get written. > If it saves it to the Container's Documents folder, for other > applications (Finder, Excel, Preview, etc) will it be visible in > /Users/nick/Documents ? No - as you point out, there's no symlink for Documents - they're different directories. > The Documents directory in the Container is NOT a symlink. It > is an actual directory. So the 2 key questions are: > > 1. Is there a way to convert from > /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to > ~/Documents/somefile.csv to display in the UI for the user? I haven't heard of anything special to help do that. I don't imagine that's something that is expected to be needed. > 2. If the file gets saved to > /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can > other applications (such as Excel) access the file from > ~/Documents/somefile.csv ? No, the container directory is hidden. It would not be visible to the Finder or most other apps without some extra work on the part of the user. Again, this is why files meant for user consumption shouldn't go into the container. > What bothers me about this proposed change is that you're taking away > a useful property (the user's $HOME) and replacing it with something > that, to me, is best done in an app's platform specific code, not in > the JDK's. And I still need to know the user's $HOME, since the > answers to my 2 questions above are probably 'no', so I'll have to > add more to my app's Mac sandbox-specific code to get it. $HOME is not accessible to a sandboxed app, except through a file dialog, and the file dialog will still take you $HOME with the updated value of user.home. Given how it all works, the usefulness of $HOME within the sandbox seems pretty low (reflected by the fact that Apple returns the Container path instead of $HOME when NSHomeDirectory is called within the sandbox). Our aim here, of course, is to require *less* platform-specific code to do the right thing, in particular to minimize extra code needed to move an app to the App Sandbox by following Apple's recommendations re: NSHomeDirectory vs getpwuid(). Thanks, -Brent From david.dehaven at oracle.com Wed Sep 11 15:11:51 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Wed, 11 Sep 2013 15:11:51 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5230E995.3090609@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> <5230E995.3090609@oracle.com> Message-ID: <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com> >>> The bottom line is, if what you have now allows you to write to >>> ~/Documents and you're sandboxed then this change should not >>> affect your application at all, except maybe in the UI if you're >>> displaying that path to the user. The user won't notice the >>> difference otherwise. >> >> My users *will* notice because I display this path in the export dialog, >> along with the other export options they can use. > > If the path displayed is coming from the selected file, then it will continue to show the correct path. I don't think I was clear on that comment... if you're building the path from say System.getProperty("user.home") + "/Documents/blah" and showing it to the user, then that's a problem. If you're showing paths returned by the open/save panels then you're fine, the user will never see the container path. -DrD- From Sergey.Bylokhov at oracle.com Thu Sep 12 04:45:29 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Sep 2013 15:45:29 +0400 Subject: [8] Review request for 8008728 [macosx] Swing. JDialog. Modal dialog goes to background In-Reply-To: <52289C45.8040609@oracle.com> References: <52289C45.8040609@oracle.com> Message-ID: <5231A959.2010704@oracle.com> Hi, Alexander. The fix looks good. Can you add additional comments about the new code in the AWTWindow.m. It should describe that the native system can bring up the NSWindow to the top even if the window is not main, and we should do some things manually. On 05.09.2013 18:59, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008728 > webrev: http://cr.openjdk.java.net/~alexsch/8008728/webrev.00 > > Suppose there are 2 frames and one modal dialog which has the first > frame as a parent. > > When we click on the second window the canBecomeMainWindow method > returns NO (the second window > is disabled because of the modal dialog) and it does not receive the > windowDidBecomeMain event. > But Mac OS X system places the second window over the modal dialog. > > The fix checks the right order of windows in the canBecomeMainWindow > method. > > Thanks, > Alexandr. > > -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Sep 12 06:14:44 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 12 Sep 2013 17:14:44 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <5230585F.600@oracle.com> References: <52305136.9040408@oracle.com> <5230585F.600@oracle.com> Message-ID: <5231BE44.5030201@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ The problem was that NSWindow is created with zero bounds and then actual bounds are set. In this case NSWindow treats big bounds as zoomed state and next zoom move the window to initial zero bounds. The fix sets actual window bounds during NSWindow creation and uses NSWindow.isZoomed flag instead of CPW.zoomed. Thanks, Alexandr. On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: > Hi, Alexander. > Looks like the main issue is that CPW.zoomed and actual state of the > NSWindow is out of sync. Does unmaximize works after the fix? > I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. > > On 11.09.2013 15:17, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >> >> The fix check if an NSWindow is in zoomed state before maximize it. >> >> Thanks, >> Alexandr. >> > > From Sergey.Bylokhov at oracle.com Thu Sep 12 06:44:32 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Sep 2013 17:44:32 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <5231BE44.5030201@oracle.com> References: <52305136.9040408@oracle.com> <5230585F.600@oracle.com> <5231BE44.5030201@oracle.com> Message-ID: <5231C540.1070407@oracle.com> Hi, Alexander. The fix looks good. On 12.09.2013 17:14, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ > > The problem was that NSWindow is created with zero bounds and then > actual bounds are set. > In this case NSWindow treats big bounds as zoomed state and next > zoom move the window to initial zero bounds. > > The fix sets actual window bounds during NSWindow creation and uses > NSWindow.isZoomed flag instead of CPW.zoomed. > > Thanks, > Alexandr. > > > On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like the main issue is that CPW.zoomed and actual state of the >> NSWindow is out of sync. Does unmaximize works after the fix? >> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >> >> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>> >>> The fix check if an NSWindow is in zoomed state before maximize it. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From sergey.bylokhov at oracle.com Thu Sep 12 13:22:37 2013 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Sep 2013 13:22:37 -0700 (PDT) Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display Message-ID: Hi, Alexander. Looks like I found another issue in the fix. PlatformWindow.initialize now uses target.getBounds(). But these bounds are not verifyed against correct values(see LWWP.setBound()) We should rearrange our initialisation code. ======================== Hi, Alexander. The fix looks good. On 12.09.2013 17:14, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ > > The problem was that NSWindow is created with zero bounds and then > actual bounds are set. > In this case NSWindow treats big bounds as zoomed state and next > zoom move the window to initial zero bounds. > > The fix sets actual window bounds during NSWindow creation and uses > NSWindow.isZoomed flag instead of CPW.zoomed. > > Thanks, > Alexandr. > > > On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like the main issue is that CPW.zoomed and actual state of the >> NSWindow is out of sync. Does unmaximize works after the fix? >> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >> >> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>> >>> The fix check if an NSWindow is in zoomed state before maximize it. >>> >>> Thanks, >>> Alexandr. >>> >> >> > -- Best regards, Sergey. From nick at transparentech.com Thu Sep 12 13:41:23 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Thu, 12 Sep 2013 22:41:23 +0200 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com> References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> <5230E995.3090609@oracle.com> <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com> Message-ID: Ok, I've tried this out with my app in the sandbox. I can confirm that opening a file dialog (NSSavePanel underneath), with a directory pointing to the Container's Documents directory (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the standard ~/Documents directory selected. If you then select a file there, say 'selected-file.txt', click OK, the dialog will return the path ~/Documents/selected-file.txt. Since I have the com.apple.security.files.user-selected.read-write entitlement in my application, I can subsequently write to this path, and the file is written in ~/Documents/selected-file.txt, not in the Container's Documents directory. So this clears up my questions about this patch. Thanks for helping me through it. Cheers, Nick On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven wrote: > > >>> The bottom line is, if what you have now allows you to write to > >>> ~/Documents and you're sandboxed then this change should not > >>> affect your application at all, except maybe in the UI if you're > >>> displaying that path to the user. The user won't notice the > >>> difference otherwise. > >> > >> My users *will* notice because I display this path in the export dialog, > >> along with the other export options they can use. > > > > If the path displayed is coming from the selected file, then it will > continue to show the correct path. > > I don't think I was clear on that comment... if you're building the path > from say System.getProperty("user.home") + "/Documents/blah" and showing it > to the user, then that's a problem. If you're showing paths returned by the > open/save panels then you're fine, the user will never see the container > path. > > -DrD- > > From david.dehaven at oracle.com Thu Sep 12 13:50:54 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 12 Sep 2013 13:50:54 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <52299FE7.2050702@oracle.com> <5229DAE7.80307@oracle.com> <6F8EED4C-44B7-49BB-AC52-D619B3B4BF00@oracle.com> <522FB8E6.4020209@oracle.com> <5230E995.3090609@oracle.com> <05F4A4A9-E77B-4D26-961F-BB972F44E95C@oracle.com> Message-ID: <99A7C5C4-0D05-41A6-A4F9-0F50B49B8416@oracle.com> No problems :) It's certainly worth knowing if there will be an issue or not. -DrD- > Ok, I've tried this out with my app in the sandbox. I can confirm that opening a file dialog (NSSavePanel underneath), with a directory pointing to the Container's Documents directory (/Users/nick/Library/Containers/my.app/Data/Documents), will show the standard Mac file selection dialog with the standard ~/Documents directory selected. If you then select a file there, say 'selected-file.txt', click OK, the dialog will return the path ~/Documents/selected-file.txt. Since I have the com.apple.security.files.user-selected.read-write entitlement in my application, I can subsequently write to this path, and the file is written in ~/Documents/selected-file.txt, not in the Container's Documents directory. > > So this clears up my questions about this patch. Thanks for helping me through it. > > Cheers, > Nick > > > > On Thu, Sep 12, 2013 at 12:11 AM, David DeHaven wrote: > > >>> The bottom line is, if what you have now allows you to write to > >>> ~/Documents and you're sandboxed then this change should not > >>> affect your application at all, except maybe in the UI if you're > >>> displaying that path to the user. The user won't notice the > >>> difference otherwise. > >> > >> My users *will* notice because I display this path in the export dialog, > >> along with the other export options they can use. > > > > If the path displayed is coming from the selected file, then it will continue to show the correct path. > > I don't think I was clear on that comment... if you're building the path from say System.getProperty("user.home") + "/Documents/blah" and showing it to the user, then that's a problem. If you're showing paths returned by the open/save panels then you're fine, the user will never see the container path. > > -DrD- > > From hs at tagtraum.com Fri Sep 13 02:32:49 2013 From: hs at tagtraum.com (Hendrik Schreiber) Date: Fri, 13 Sep 2013 11:32:49 +0200 Subject: 7_40 - sweet! Message-ID: Hey guys, started using 1.7.0_40 a couple of days ago and it looks like I can't find any glaring bugs anymore. Umlauts in files work fine, FileDialog can be used to open directories, ... Looks good. Thank you. -hendrik From david.dehaven at oracle.com Fri Sep 13 08:35:00 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 13 Sep 2013 08:35:00 -0700 Subject: 7_40 - sweet! In-Reply-To: References: Message-ID: <61D9FF25-AA7B-43AF-8B6A-FBD0DB1F9387@oracle.com> > Hey guys, > > started using 1.7.0_40 a couple of days ago and it looks like I can't find any glaring bugs anymore. > Umlauts in files work fine, FileDialog can be used to open directories, ... > Looks good. > > Thank you. Thanks for the feedback! We really do appreciate it :) -DrD- From curtis at stsci.edu Fri Sep 13 08:42:10 2013 From: curtis at stsci.edu (Gary Curtis) Date: Fri, 13 Sep 2013 15:42:10 +0000 Subject: 7_40 - sweet! In-Reply-To: <61D9FF25-AA7B-43AF-8B6A-FBD0DB1F9387@oracle.com> References: <61D9FF25-AA7B-43AF-8B6A-FBD0DB1F9387@oracle.com> Message-ID: <8BFFFF8D-B54F-45E1-B751-F7BF5DB0A86A@stsci.edu> I would like add my thanks. We have been planning to deliver our fall release with Java 7 and our user base is 80% Mac. Prior to u40 there were issues that were probably show stoppers but u40 looks great so far. Thanks, Gary. -- "Simplify and add lightness" - Colin Chapman of Lotus On Sep 13, 2013, at 11:35 AM, David DeHaven > wrote: Hey guys, started using 1.7.0_40 a couple of days ago and it looks like I can't find any glaring bugs anymore. Umlauts in files work fine, FileDialog can be used to open directories, ... Looks good. Thank you. Thanks for the feedback! We really do appreciate it :) -DrD- From brent.christian at oracle.com Fri Sep 13 10:20:14 2013 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 13 Sep 2013 10:20:14 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com> References: <5228F7F0.8080605@oracle.com> <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com> Message-ID: <5233494E.3000309@oracle.com> Replying to Alan and Mike... On 9/6/13 2:27 AM, Alan Bateman wrote: > On 05/09/2013 22:30, Brent Christian wrote: > > I don't know Cocoa memory management but from a quick look at the > NSAutoreleasePool docs then what you seems to be right. Folks on > macosx-port-dev would be better to comment on that. Perhaps Dave could comment? > I see that createUTF8CString doesn't handle malloc failing and it's > not clear how CFStringGetCString behaves when called with NULL. In > any case, this is all early startup and if we have malloc failing > this early then we aren't going to get very far. Right. > One comment on the error case (fallback to "?") as this is now > duplicated. It might be better to have this fallback in one place > (GetJavaProperties) as I'm pretty sure we'll need to re-examine it > at some point Done, new webrev is here: http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/ On 9/6/13 4:09 PM, Mike Duigou wrote: > > I am surprised that strdup isn't needed for the constant "?" string > but java_props_md.c seems to include other constant strings in sprops > so I will assume it is just never deallocated in the lifetime of the > JVM. My understanding is that C string literals go into static storage, and live for the life of the program. Thanks, -Brent From david.dehaven at oracle.com Fri Sep 13 10:36:20 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 13 Sep 2013 10:36:20 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: <5233494E.3000309@oracle.com> References: <5228F7F0.8080605@oracle.com> <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com> <5233494E.3000309@oracle.com> Message-ID: >> I don't know Cocoa memory management but from a quick look at the >> NSAutoreleasePool docs then what you seems to be right. Folks on >> macosx-port-dev would be better to comment on that. > > Perhaps Dave could comment? The use of NSAutoreleasePool is fine in this case. >> I see that createUTF8CString doesn't handle malloc failing and it's >> not clear how CFStringGetCString behaves when called with NULL. In >> any case, this is all early startup and if we have malloc failing >> this early then we aren't going to get very far. > > Right. CFStringGetCString does not handle NULL CFString, it will seg fault. We do a NULL check before calling it though so we're safe. >> One comment on the error case (fallback to "?") as this is now >> duplicated. It might be better to have this fallback in one place >> (GetJavaProperties) as I'm pretty sure we'll need to re-examine it >> at some point > > Done, new webrev is here: > > http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/ Everything looks fine to me. >> I am surprised that strdup isn't needed for the constant "?" string >> but java_props_md.c seems to include other constant strings in sprops >> so I will assume it is just never deallocated in the lifetime of the >> JVM. > > My understanding is that C string literals go into static storage, and live for the life of the program. Yes, they end up in a read-only TEXT section of the executable, they cannot be deallocated without unloading the entire binary. -DrD- From david.dehaven at oracle.com Fri Sep 13 10:54:19 2013 From: david.dehaven at oracle.com (David DeHaven) Date: Fri, 13 Sep 2013 10:54:19 -0700 Subject: RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx] In-Reply-To: References: <5228F7F0.8080605@oracle.com> <36AAED98-5E1D-47CC-8DC6-3D01FC05318D@oracle.com> <5233494E.3000309@oracle.com> Message-ID: <942FA6A0-C30F-4BB2-8509-4ECFB63F79A3@oracle.com> >>> Done, new webrev is here: >> >> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/ >> >> >> On 9/6/13 4:09 PM, Mike Duigou wrote: >>> >>> I am surprised that strdup isn't needed for the constant "?" string >>> but java_props_md.c seems to include other constant strings in sprops >>> so I will assume it is just never deallocated in the lifetime of the >>> JVM. >> >> My understanding is that C string literals go into static storage, and live for the life of the program. > > My concern was mostly that nobody ever attempts to call free(sprops.user_home) which does't seem to happen. Does it happen for the other strdup'ed fields? I didn't look at the code deeply enough to answer it myself... at first glance it doesn't introduce any leaks that weren't already there. -DrD- From anthony.petrov at oracle.com Mon Sep 16 05:09:05 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 16 Sep 2013 16:09:05 +0400 Subject: [8] Review request for 8008728 [macosx] Swing. JDialog. Modal dialog goes to background In-Reply-To: <52289C45.8040609@oracle.com> References: <52289C45.8040609@oracle.com> Message-ID: <5236F4E1.7050301@oracle.com> Hi Alexander, The fix looks good overall. A couple of minor issues: src/macosx/native/sun/awt/AWTWindow.m > 369 if(!self.isEnabled){ Please add missing spaces. > 377 "checkBlockingAndOrder", "()Z"); > 378 JNFCallVoidMethod(env, platformWindow, jm_checkBlockingAndOrder); This is actually a Boolean method, not a Void one. Please use the correct JNFCall* function. As for the test, how does it fail? I see that all exceptions get thrown on the test thread, not the main thread. Does this cause the jtreg harness to consider the test failed or not? -- best regards, Anthony On 09/05/13 18:59, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008728 > webrev: http://cr.openjdk.java.net/~alexsch/8008728/webrev.00 > > Suppose there are 2 frames and one modal dialog which has the first > frame as a parent. > > When we click on the second window the canBecomeMainWindow method > returns NO (the second window > is disabled because of the modal dialog) and it does not receive the > windowDidBecomeMain event. > But Mac OS X system places the second window over the modal dialog. > > The fix checks the right order of windows in the canBecomeMainWindow > method. > > Thanks, > Alexandr. > From anthony.petrov at oracle.com Mon Sep 16 05:32:05 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 16 Sep 2013 16:32:05 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <5231BE44.5030201@oracle.com> References: <52305136.9040408@oracle.com> <5230585F.600@oracle.com> <5231BE44.5030201@oracle.com> Message-ID: <5236FA45.1000909@oracle.com> Hi Alexander, Does the test test/java/awt/Frame/HideMaximized/HideMaximized.java pass with this fix? If in your test (MaximizedToMaximized) you exchange the setBounds() and setVisible(true) lines, does it still pass? If both answers are "yes", then I'm OK with your fix. -- best regards, Anthony On 09/12/13 17:14, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ > > The problem was that NSWindow is created with zero bounds and then > actual bounds are set. > In this case NSWindow treats big bounds as zoomed state and next zoom > move the window to initial zero bounds. > > The fix sets actual window bounds during NSWindow creation and uses > NSWindow.isZoomed flag instead of CPW.zoomed. > > Thanks, > Alexandr. > > > On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like the main issue is that CPW.zoomed and actual state of the >> NSWindow is out of sync. Does unmaximize works after the fix? >> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >> >> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>> >>> The fix check if an NSWindow is in zoomed state before maximize it. >>> >>> Thanks, >>> Alexandr. >>> >> >> > From Koen.VanDenBorre at esko.com Thu Sep 19 05:24:00 2013 From: Koen.VanDenBorre at esko.com (Van Den Borre, Koen) Date: Thu, 19 Sep 2013 12:24:00 +0000 Subject: [macosx] JTableHeader painting error with Java 8 on Mac In-Reply-To: <51B9BA66.2080809@oracle.com> References: <02623B53-A31D-4ED6-AAAB-F4896A6FD56D@esko.com> <51B9B2F2.2000805@oracle.com> <51B9BA66.2080809@oracle.com> Message-ID: <11C549F6-BD9C-4A1F-B6E4-FF91B5BFA939@esko.com> Hi, I verified that the proposed fix does indeed solve this issue. Can this change be reviewed and checked in please. Thanks, Koen. On 13 Jun 2013, at 14:26, Alexander Scherbatiy wrote: > On 6/13/2013 3:54 PM, Alexander Scherbatiy wrote: >> On 6/11/2013 4:47 PM, Van Den Borre, Koen wrote: >>> Hi, >>> >>> I noticed that on Java 8 on Mac, the JTableHeader looks clipped (the bottom line is not visible). >>> This was not an issue in Java 6. >> >> It seems that there should be newHeight + 1 for the border painting: >> http://hg.openjdk.java.net/jdk8/awt/jdk/file/a7d943998bd3/src/macosx/classes/com/apple/laf/AquaTableHeaderBorder.java >> >> 102 final int newX = x; >> 103 final int newY = y; >> 104 final int newWidth = width; >> 105 final int newHeight = height; >> 106 >> 107 painter.paint(g, c, newX - 1, newY - 1, newWidth + 1, newHeight); >> >> This is a good chance for the JDK 8 patch contribution. > > I have created the issue 8016524 [macosx] Bottom line is not visible for JTableHeader > http://bugs.sun.com/view_bug.do?bug_id=8016524 > > It should be public available soon. > > Thanks, > Alexandr. >> >> Thanks, >> Alexandr. >> >>> >>> Here is a simple test case: >>> >>> import javax.swing.JFrame; >>> import javax.swing.JScrollPane; >>> import javax.swing.JTable; >>> import javax.swing.SwingUtilities; >>> >>> public class JTableHeaderTest >>> { >>> public void run() >>> { >>> JTable table = new JTable(2, 5); >>> >>> JScrollPane scrollableTable = new JScrollPane(table); >>> >>> JFrame frame = new JFrame(); >>> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >>> frame.getContentPane().add(scrollableTable); >>> frame.setSize(300, 300); >>> frame.setLocationRelativeTo(null); >>> frame.setVisible(true); >>> } >>> >>> public static void main(String[] arguments) >>> { >>> SwingUtilities.invokeLater(new Runnable() >>> { >>> @Override >>> public void run() >>> { >>> JTableHeaderTest test = new JTableHeaderTest(); >>> test.run(); >>> } >>> }); >>> } >>> } >> > From martijnverburg at gmail.com Thu Sep 19 08:38:45 2013 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 19 Sep 2013 16:38:45 +0100 Subject: 7_40 - sweet! In-Reply-To: <8BFFFF8D-B54F-45E1-B751-F7BF5DB0A86A@stsci.edu> References: <61D9FF25-AA7B-43AF-8B6A-FBD0DB1F9387@oracle.com> <8BFFFF8D-B54F-45E1-B751-F7BF5DB0A86A@stsci.edu> Message-ID: +1 very happy Mac user here (my three desktop apps are bug free!) Cheers, Martijn On 13 September 2013 16:42, Gary Curtis wrote: > I would like add my thanks. > > We have been planning to deliver our fall release with Java 7 and our user > base is 80% Mac. Prior to > u40 there were issues that were probably show stoppers but u40 looks great > so far. > > Thanks, > Gary. > -- > "Simplify and add lightness" > - Colin Chapman of Lotus > > > > On Sep 13, 2013, at 11:35 AM, David DeHaven > wrote: > > > Hey guys, > > started using 1.7.0_40 a couple of days ago and it looks like I can't find > any glaring bugs anymore. > Umlauts in files work fine, FileDialog can be used to open directories, ... > Looks good. > > Thank you. > > Thanks for the feedback! We really do appreciate it :) > > -DrD- > > > From alexandr.scherbatiy at oracle.com Mon Sep 23 06:11:01 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Sep 2013 17:11:01 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: References: Message-ID: <52403DE5.7050006@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ The bounds checking is moved to a separated method. The fix checks bounds before unativeCreateNSWindow method call. Thanks, Alexandr. On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: > Hi, Alexander. > Looks like I found another issue in the fix. > PlatformWindow.initialize now uses target.getBounds(). But these bounds are not verifyed against correct values(see LWWP.setBound()) > We should rearrange our initialisation code. > > ======================== > > Hi, Alexander. > The fix looks good. > > On 12.09.2013 17:14, Alexander Scherbatiy wrote: >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >> >> The problem was that NSWindow is created with zero bounds and then >> actual bounds are set. >> In this case NSWindow treats big bounds as zoomed state and next >> zoom move the window to initial zero bounds. >> >> The fix sets actual window bounds during NSWindow creation and uses >> NSWindow.isZoomed flag instead of CPW.zoomed. >> >> Thanks, >> Alexandr. >> >> >> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Looks like the main issue is that CPW.zoomed and actual state of the >>> NSWindow is out of sync. Does unmaximize works after the fix? >>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>> >>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>> >>>> The fix check if an NSWindow is in zoomed state before maximize it. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> > From anthony.petrov at oracle.com Mon Sep 23 07:01:49 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 23 Sep 2013 18:01:49 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52403DE5.7050006@oracle.com> References: <52403DE5.7050006@oracle.com> Message-ID: <524049CD.8080408@oracle.com> Hi Alexander, I'll ask again: Does the test test/java/awt/Frame/HideMaximized/HideMaximized.java pass with this fix? If in your test (MaximizedToMaximized) you exchange the setBounds() and setVisible(true) lines, does it still pass? If both answers are "yes", then I'm OK with your fix. BTW, the getChekedBounds() might be better named constrainBounds(). We've used this method name in other toolkits for similar purposes. -- best regards, Anthony On 09/23/13 17:11, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ > > The bounds checking is moved to a separated method. > The fix checks bounds before unativeCreateNSWindow method call. > > Thanks, > Alexandr. > > On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like I found another issue in the fix. >> PlatformWindow.initialize now uses target.getBounds(). But these >> bounds are not verifyed against correct values(see LWWP.setBound()) >> We should rearrange our initialisation code. >> >> ======================== >> >> Hi, Alexander. >> The fix looks good. >> >> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>> >>> The problem was that NSWindow is created with zero bounds and then >>> actual bounds are set. >>> In this case NSWindow treats big bounds as zoomed state and next >>> zoom move the window to initial zero bounds. >>> >>> The fix sets actual window bounds during NSWindow creation and uses >>> NSWindow.isZoomed flag instead of CPW.zoomed. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Looks like the main issue is that CPW.zoomed and actual state of the >>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>> >>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>> >>>>> The fix check if an NSWindow is in zoomed state before maximize it. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >> > From alexandr.scherbatiy at oracle.com Mon Sep 23 07:07:27 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Sep 2013 18:07:27 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <524049CD.8080408@oracle.com> References: <52403DE5.7050006@oracle.com> <524049CD.8080408@oracle.com> Message-ID: <52404B1F.4000204@oracle.com> On 9/23/2013 6:01 PM, Anthony Petrov wrote: > Hi Alexander, > > I'll ask again: > > Does the test test/java/awt/Frame/HideMaximized/HideMaximized.java > pass with this fix? Yes. > > If in your test (MaximizedToMaximized) you exchange the setBounds() > and setVisible(true) lines, does it still pass? Yes (in both cases with the fix and without the fix). Thanks, Alexandr. > > If both answers are "yes", then I'm OK with your fix. > > BTW, the getChekedBounds() might be better named constrainBounds(). > We've used this method name in other toolkits for similar purposes. > > -- > best regards, > Anthony > > On 09/23/13 17:11, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ >> >> The bounds checking is moved to a separated method. >> The fix checks bounds before unativeCreateNSWindow method call. >> >> Thanks, >> Alexandr. >> >> On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >>> Hi, Alexander. >>> Looks like I found another issue in the fix. >>> PlatformWindow.initialize now uses target.getBounds(). But these >>> bounds are not verifyed against correct values(see LWWP.setBound()) >>> We should rearrange our initialisation code. >>> >>> ======================== >>> >>> Hi, Alexander. >>> The fix looks good. >>> >>> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>>> >>>> The problem was that NSWindow is created with zero bounds and then >>>> actual bounds are set. >>>> In this case NSWindow treats big bounds as zoomed state and next >>>> zoom move the window to initial zero bounds. >>>> >>>> The fix sets actual window bounds during NSWindow creation and uses >>>> NSWindow.isZoomed flag instead of CPW.zoomed. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> >>>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>>> Hi, Alexander. >>>>> Looks like the main issue is that CPW.zoomed and actual state of the >>>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>>> >>>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>>> >>>>>> The fix check if an NSWindow is in zoomed state before maximize it. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>> >>> >> From anthony.petrov at oracle.com Mon Sep 23 07:10:22 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 23 Sep 2013 18:10:22 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52404B1F.4000204@oracle.com> References: <52403DE5.7050006@oracle.com> <524049CD.8080408@oracle.com> <52404B1F.4000204@oracle.com> Message-ID: <52404BCE.9000700@oracle.com> Thanks for the clarifications. The fix looks good then. -- best regards, Anthony On 09/23/13 18:07, Alexander Scherbatiy wrote: > On 9/23/2013 6:01 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> I'll ask again: >> >> Does the test test/java/awt/Frame/HideMaximized/HideMaximized.java >> pass with this fix? > Yes. >> >> If in your test (MaximizedToMaximized) you exchange the setBounds() >> and setVisible(true) lines, does it still pass? > Yes (in both cases with the fix and without the fix). > > Thanks, > Alexandr. > >> >> If both answers are "yes", then I'm OK with your fix. >> >> BTW, the getChekedBounds() might be better named constrainBounds(). >> We've used this method name in other toolkits for similar purposes. >> >> -- >> best regards, >> Anthony >> >> On 09/23/13 17:11, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ >>> >>> The bounds checking is moved to a separated method. >>> The fix checks bounds before unativeCreateNSWindow method call. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Looks like I found another issue in the fix. >>>> PlatformWindow.initialize now uses target.getBounds(). But these >>>> bounds are not verifyed against correct values(see LWWP.setBound()) >>>> We should rearrange our initialisation code. >>>> >>>> ======================== >>>> >>>> Hi, Alexander. >>>> The fix looks good. >>>> >>>> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>>>> >>>>> The problem was that NSWindow is created with zero bounds and then >>>>> actual bounds are set. >>>>> In this case NSWindow treats big bounds as zoomed state and next >>>>> zoom move the window to initial zero bounds. >>>>> >>>>> The fix sets actual window bounds during NSWindow creation and uses >>>>> NSWindow.isZoomed flag instead of CPW.zoomed. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> Looks like the main issue is that CPW.zoomed and actual state of the >>>>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>>>> >>>>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>>>> >>>>>>> The fix check if an NSWindow is in zoomed state before maximize it. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>> >>>> >>> > From alexandr.scherbatiy at oracle.com Mon Sep 23 07:10:21 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 23 Sep 2013 18:10:21 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52404B1F.4000204@oracle.com> References: <52403DE5.7050006@oracle.com> <524049CD.8080408@oracle.com> <52404B1F.4000204@oracle.com> Message-ID: <52404BCD.2000204@oracle.com> On 9/23/2013 6:07 PM, Alexander Scherbatiy wrote: > On 9/23/2013 6:01 PM, Anthony Petrov wrote: >> Hi Alexander, >> >> I'll ask again: >> >> Does the test test/java/awt/Frame/HideMaximized/HideMaximized.java >> pass with this fix? > Yes. >> >> If in your test (MaximizedToMaximized) you exchange the setBounds() >> and setVisible(true) lines, does it still pass? > Yes (in both cases with the fix and without the fix). Sorry. In this case the test passes with the fix and fails without the fix. Thanks, Alexandr. > > Thanks, > Alexandr. > >> >> If both answers are "yes", then I'm OK with your fix. >> >> BTW, the getChekedBounds() might be better named constrainBounds(). >> We've used this method name in other toolkits for similar purposes. >> >> -- >> best regards, >> Anthony >> >> On 09/23/13 17:11, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ >>> >>> The bounds checking is moved to a separated method. >>> The fix checks bounds before unativeCreateNSWindow method call. >>> >>> Thanks, >>> Alexandr. >>> >>> On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Looks like I found another issue in the fix. >>>> PlatformWindow.initialize now uses target.getBounds(). But these >>>> bounds are not verifyed against correct values(see LWWP.setBound()) >>>> We should rearrange our initialisation code. >>>> >>>> ======================== >>>> >>>> Hi, Alexander. >>>> The fix looks good. >>>> >>>> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>>>> >>>>> The problem was that NSWindow is created with zero bounds and then >>>>> actual bounds are set. >>>>> In this case NSWindow treats big bounds as zoomed state and next >>>>> zoom move the window to initial zero bounds. >>>>> >>>>> The fix sets actual window bounds during NSWindow creation and uses >>>>> NSWindow.isZoomed flag instead of CPW.zoomed. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> >>>>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> Looks like the main issue is that CPW.zoomed and actual state of the >>>>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>>>> >>>>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>>>> >>>>>>> The fix check if an NSWindow is in zoomed state before maximize it. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>> >>>> >>> > From artem.ananiev at oracle.com Tue Sep 24 07:24:03 2013 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Tue, 24 Sep 2013 18:24:03 +0400 Subject: [8] Review request for 8008728 [macosx] Swing. JDialog. Modal dialog goes to background In-Reply-To: <5231A959.2010704@oracle.com> References: <52289C45.8040609@oracle.com> <5231A959.2010704@oracle.com> Message-ID: <5241A083.6050002@oracle.com> On 9/12/2013 3:45 PM, Sergey Bylokhov wrote: > Hi, Alexander. > The fix looks good. > Can you add additional comments about the new code in the AWTWindow.m. > It should describe that the native system can bring up the NSWindow to > the top even if the window is not main, and we should do some things > manually. I agree. The fix looks good, but comments in the bug would be very welcome. Thanks, Artem > On 05.09.2013 18:59, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008728 >> webrev: http://cr.openjdk.java.net/~alexsch/8008728/webrev.00 >> >> Suppose there are 2 frames and one modal dialog which has the first >> frame as a parent. >> >> When we click on the second window the canBecomeMainWindow method >> returns NO (the second window >> is disabled because of the modal dialog) and it does not receive the >> windowDidBecomeMain event. >> But Mac OS X system places the second window over the modal dialog. >> >> The fix checks the right order of windows in the canBecomeMainWindow >> method. >> >> Thanks, >> Alexandr. >> >> > > From jfinley at tech4learning.com Tue Sep 24 09:50:26 2013 From: jfinley at tech4learning.com (Jessica Finley) Date: Tue, 24 Sep 2013 10:50:26 -0600 Subject: Invalid Signature - Mac App Store Message-ID: Hiya folks, We're submitting our app to the Mac App Store and getting the following warning: > Invalid Signature - the nested app bundle Java SE 8 at path My App.app/Contents/PlugIns/1.8.0.jre is not signed > I'm stumped as to why I'm getting this warning because I sign all of the individual components of the jre bundle (jnilibs, jars, dylibs) and then after that, I sign the jre bundle itself. Is there some magical order to doing things that I'm missing? Has anyone else successfully submitted a java app to the Mac App Store without iTunes Connect warning about the jre not being signed? If so, could you please drop me a hint? Thank you! Jess From Sergey.Bylokhov at oracle.com Tue Sep 24 11:43:10 2013 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Sep 2013 11:43:10 -0700 (PDT) Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52403DE5.7050006@oracle.com> References: <52403DE5.7050006@oracle.com> Message-ID: <5241DD3E.1030501@oracle.com> Hi, Alexander. The fix looks good. On 23.09.2013 17:11, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ > > The bounds checking is moved to a separated method. > The fix checks bounds before unativeCreateNSWindow method call. > > Thanks, > Alexandr. > > On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >> Hi, Alexander. >> Looks like I found another issue in the fix. >> PlatformWindow.initialize now uses target.getBounds(). But these >> bounds are not verifyed against correct values(see LWWP.setBound()) >> We should rearrange our initialisation code. >> >> ======================== >> >> Hi, Alexander. >> The fix looks good. >> >> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>> >>> The problem was that NSWindow is created with zero bounds and then >>> actual bounds are set. >>> In this case NSWindow treats big bounds as zoomed state and next >>> zoom move the window to initial zero bounds. >>> >>> The fix sets actual window bounds during NSWindow creation and uses >>> NSWindow.isZoomed flag instead of CPW.zoomed. >>> >>> Thanks, >>> Alexandr. >>> >>> >>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>> Hi, Alexander. >>>> Looks like the main issue is that CPW.zoomed and actual state of the >>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>> >>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>> >>>>> The fix check if an NSWindow is in zoomed state before maximize >>>>> it. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >> > -- Best regards, Sergey. From nick at transparentech.com Tue Sep 24 11:49:15 2013 From: nick at transparentech.com (Nicholas Rahn) Date: Tue, 24 Sep 2013 20:49:15 +0200 Subject: Invalid Signature - Mac App Store In-Reply-To: References: Message-ID: Hi. I sign all jars and dylibs under the MyApp.app/Contents directory. Then I sign the JVM bundle (in my case, MyApp.app/Contents/Plugins/1.8.0.jdk). Then I sign the executable, MyApp.app/Contents/MacOS/MyApp. Then I sign the app, MyApp.app. I submit the pkg using Application Loader and haven't had a problem with invalid signatures. -Nick On Tue, Sep 24, 2013 at 6:50 PM, Jessica Finley wrote: > Hiya folks, > > We're submitting our app to the Mac App Store and getting the following > warning: > > Invalid Signature - the nested app bundle Java SE 8 at path My > App.app/Contents/PlugIns/1.8.0.jre is not signed > > > > > I'm stumped as to why I'm getting this warning because I sign all of the > individual components of the jre bundle (jnilibs, jars, dylibs) and then > after that, I sign the jre bundle itself. Is there some magical order to > doing things that I'm missing? Has anyone else successfully submitted a > java app to the Mac App Store without iTunes Connect warning about the jre > not being signed? If so, could you please drop me a hint? > > Thank you! > Jess > > From alexandr.scherbatiy at oracle.com Wed Sep 25 07:47:04 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 25 Sep 2013 18:47:04 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <52404BCE.9000700@oracle.com> References: <52403DE5.7050006@oracle.com> <524049CD.8080408@oracle.com> <52404B1F.4000204@oracle.com> <52404BCE.9000700@oracle.com> Message-ID: <5242F768.3020405@oracle.com> On 9/23/2013 6:10 PM, Anthony Petrov wrote: >>> >>> BTW, the getChekedBounds() might be better named constrainBounds(). >>> We've used this method name in other toolkits for similar purposes. Could you review the updated fix where the getChekedBounds() is renamed to constrainBounds() http://cr.openjdk.java.net/~alexsch/8007219/webrev.03/ Thanks, Alexandr. >>> >>> -- >>> best regards, >>> Anthony >>> >>> On 09/23/13 17:11, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ >>>> >>>> The bounds checking is moved to a separated method. >>>> The fix checks bounds before unativeCreateNSWindow method call. >>>> >>>> Thanks, >>>> Alexandr. >>>> >>>> On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >>>>> Hi, Alexander. >>>>> Looks like I found another issue in the fix. >>>>> PlatformWindow.initialize now uses target.getBounds(). But these >>>>> bounds are not verifyed against correct values(see LWWP.setBound()) >>>>> We should rearrange our initialisation code. >>>>> >>>>> ======================== >>>>> >>>>> Hi, Alexander. >>>>> The fix looks good. >>>>> >>>>> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>>>>> Could you review the updated fix: >>>>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>>>>> >>>>>> The problem was that NSWindow is created with zero bounds and then >>>>>> actual bounds are set. >>>>>> In this case NSWindow treats big bounds as zoomed state and next >>>>>> zoom move the window to initial zero bounds. >>>>>> >>>>>> The fix sets actual window bounds during NSWindow creation and uses >>>>>> NSWindow.isZoomed flag instead of CPW.zoomed. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>>>> >>>>>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>>>>> Hi, Alexander. >>>>>>> Looks like the main issue is that CPW.zoomed and actual state of >>>>>>> the >>>>>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>>>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>>>>> >>>>>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you review the fix: >>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>>>>> >>>>>>>> The fix check if an NSWindow is in zoomed state before maximize >>>>>>>> it. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Alexandr. >>>>>>>> >>>>>>> >>>>> >>>> >> From alexandr.scherbatiy at oracle.com Wed Sep 25 07:58:54 2013 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 25 Sep 2013 18:58:54 +0400 Subject: [8] Review request for 8008728 [macosx] Swing. JDialog. Modal dialog goes to background In-Reply-To: <5236F4E1.7050301@oracle.com> References: <52289C45.8040609@oracle.com> <5236F4E1.7050301@oracle.com> Message-ID: <5242FA2E.2070308@oracle.com> On 9/16/2013 4:09 PM, Anthony Petrov wrote: > Hi Alexander, > > The fix looks good overall. A couple of minor issues: > > src/macosx/native/sun/awt/AWTWindow.m >> 369 if(!self.isEnabled){ > > Please add missing spaces. > >> 377 "checkBlockingAndOrder", "()Z"); >> 378 JNFCallVoidMethod(env, platformWindow, >> jm_checkBlockingAndOrder); > > This is actually a Boolean method, not a Void one. Please use the > correct JNFCall* function. Sorry. I missed your comments before the push. I have created new issue 8025438 [macosx] right JNFCall* method should be used in JDK-8008728 fix > As for the test, how does it fail? I see that all exceptions get > thrown on the test thread, not the main thread. Does this cause the > jtreg harness to consider the test failed or not? Yes. The jtreg fails the test without the fix. The modalDialog.setVisible(true) call blocks the thread. May be there is a better way to test a modal dialog behaviour. Thanks, Alexandr. > > -- > best regards, > Anthony > > On 09/05/13 18:59, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008728 >> webrev: http://cr.openjdk.java.net/~alexsch/8008728/webrev.00 >> >> Suppose there are 2 frames and one modal dialog which has the first >> frame as a parent. >> >> When we click on the second window the canBecomeMainWindow method >> returns NO (the second window >> is disabled because of the modal dialog) and it does not receive the >> windowDidBecomeMain event. >> But Mac OS X system places the second window over the modal dialog. >> >> The fix checks the right order of windows in the canBecomeMainWindow >> method. >> >> Thanks, >> Alexandr. >> From anthony.petrov at oracle.com Wed Sep 25 10:52:44 2013 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Wed, 25 Sep 2013 21:52:44 +0400 Subject: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display In-Reply-To: <5242F768.3020405@oracle.com> References: <52403DE5.7050006@oracle.com> <524049CD.8080408@oracle.com> <52404B1F.4000204@oracle.com> <52404BCE.9000700@oracle.com> <5242F768.3020405@oracle.com> Message-ID: <524322EC.9020909@oracle.com> The fix looks fine to me. Thanks for the update. -- best regards, Anthony On 09/25/2013 06:47 PM, Alexander Scherbatiy wrote: > On 9/23/2013 6:10 PM, Anthony Petrov wrote: >>>> >>>> BTW, the getChekedBounds() might be better named constrainBounds(). >>>> We've used this method name in other toolkits for similar purposes. > > Could you review the updated fix where the getChekedBounds() is > renamed to constrainBounds() > http://cr.openjdk.java.net/~alexsch/8007219/webrev.03/ > > Thanks, > Alexandr. > >>>> >>>> -- >>>> best regards, >>>> Anthony >>>> >>>> On 09/23/13 17:11, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.02/ >>>>> >>>>> The bounds checking is moved to a separated method. >>>>> The fix checks bounds before unativeCreateNSWindow method call. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>> On 9/13/2013 12:22 AM, Sergey Bylokhov wrote: >>>>>> Hi, Alexander. >>>>>> Looks like I found another issue in the fix. >>>>>> PlatformWindow.initialize now uses target.getBounds(). But these >>>>>> bounds are not verifyed against correct values(see LWWP.setBound()) >>>>>> We should rearrange our initialisation code. >>>>>> >>>>>> ======================== >>>>>> >>>>>> Hi, Alexander. >>>>>> The fix looks good. >>>>>> >>>>>> On 12.09.2013 17:14, Alexander Scherbatiy wrote: >>>>>>> Could you review the updated fix: >>>>>>> http://cr.openjdk.java.net/~alexsch/8007219/webrev.01/ >>>>>>> >>>>>>> The problem was that NSWindow is created with zero bounds and then >>>>>>> actual bounds are set. >>>>>>> In this case NSWindow treats big bounds as zoomed state and next >>>>>>> zoom move the window to initial zero bounds. >>>>>>> >>>>>>> The fix sets actual window bounds during NSWindow creation and uses >>>>>>> NSWindow.isZoomed flag instead of CPW.zoomed. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>>>> >>>>>>> On 9/11/2013 3:47 PM, Sergey Bylokhov wrote: >>>>>>>> Hi, Alexander. >>>>>>>> Looks like the main issue is that CPW.zoomed and actual state of >>>>>>>> the >>>>>>>> NSWindow is out of sync. Does unmaximize works after the fix? >>>>>>>> I suggest to remove CPW.zoomed and use NSWindow.isZoomed instead. >>>>>>>> >>>>>>>> On 11.09.2013 15:17, Alexander Scherbatiy wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you review the fix: >>>>>>>>> bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 >>>>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 >>>>>>>>> >>>>>>>>> The fix check if an NSWindow is in zoomed state before maximize >>>>>>>>> it. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Alexandr. >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >