JDK-8015393 : Step 8:The application will be blocked for S1 users.
  • Type: Bug
  • Component: deploy
  • Affected Version: 7u25,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86
  • Submitted: 2013-05-24
  • Updated: 2014-05-07
  • Resolved: 2014-05-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8038121 - Java is still Enabled for user O1, and the applications in step 5 and step 6 can't be blocked.
Description
Component:common
Bundle:Jre7u25b12
Platform:Mac OS 10.8 (x64) 

Steps(this test case is from new_framework/tests/common/manual/disableJavaManual_NonMultipleJRE/testcases/disableJavaManual_NonMultipleJREScenarios/testAdminDisabledFirstThenStandardUserPrivileged.html) 

1.Install test JRE ( it should supports "Enable Java" feature ), do the next preparation settings:
User A's Java is enabled. 
User S1's Java is enabled. 
User S2's Java is disabled. 
2.Login as User A, disable Java
3.Login as User S1, enable Java, providing Admin credential when asked.
4.Make sure:
User A's Java is disabled. 
User S1's Java is enabled. 
User S2's Java is disabled. 
5.Make sure that java is disabled for users: A/S2 and enabled for S1
6.(ONLY apply to JDK 8 and JDK7 version 7u11 and later: Before applets/javaws applications get launched, a security warning dialog will pop-up asking you if you want to run the application. Click "Run" to accept. NOTE: This is NOT a cert dialog)
7.Run sample applets and make sure that it's blocked for A/S2 users ( browser will behave as if java plugin is not installed ) and NOT blocked for S1 users: 
http://localhost:8080/disableJavaManual_NonMultipleJRE/html/testAppletWithAppletTag.html 
http://localhost:8080/disableJavaManual_NonMultipleJRE/html/testAppletWithObjectTag.html 
http://localhost:8080/disableJavaManual_NonMultipleJRE/html/testDTApplet.html 
http://localhost:8080/disableJavaManual_NonMultipleJRE/html/testJnlpApplet.html 
8.Skip this assertaion on Unix and Linux (Applies to Windows and Mac Only). Try to start javaws application SUITE_DIR/new_framework/tests/common/manual/disableJavaManual_NonMultipleJRE/jnlp/testJavawsLaunchOnCLI.jnlp from windows explorer, make sure jnlp association is blocked for A/S2 users and NOT blocked for S1 users

The actual result: 
Step 8:The application will be blocked for S1 users.Please refer to 1.jpg
Comments
Resolving as a duplicate as it will be fixed under JDK-8029309
07-05-2014
Before we fix this we need to revise the user experience spec behind this control.
24-03-2014
disableJavaManual_NonMultipleJREScenarios/testAdminDisabledFirstThenStandardUserPrivileged disableJavaManual_NonMultipleJREScenarios/testAdminEnabledFirstThenStandardUserPrivileged_FinallyEnabled disableJavaManual_NonMultipleJREScenarios/testDisabledByStandardUser disableJavaManual_NonMultipleJREScenarios/testReinstallEnable disableJavaManual_NonMultipleJREScenarios/testUpgradeUninstallEnable The same issue will be happened with 8b92 on win7 sp1 x64 disableJavaManual_MultipleJREScenarios/testDowngradeAwareNotUninstallEnable disableJavaManual_MultipleJREScenarios/testDowngradeAwareThenReinstallEnable disableJavaManual_MultipleJREScenarios/testDowngradeUnawareNotUninstallEnable disableJavaManual_MultipleJREScenarios/testDowngradeUnawareThenReinstallEnable
07-06-2013
SQE-OK to defer this issue to 7u40
29-05-2013
Where the UI is completely wrong is the behavior of the Cancel button. That button needs to completely cancel the operation not fallback on a different behavior. This is why the process is confusing. "I clicked Cancel and it still disabled Java..."
29-05-2013
What is not in the original design is that a user can enable Java just for themselves with the Admin credentials. The assumption we made is if the user has the Admin credentials, then enabling or disabling Java would occur globally. However this is not how it is implemented... When User S1 enables Java with the Admin credential, it may enable Java globally, but then it disables Java individually for the other users (so their existing disabled state doesn't change). The reverse is not true. If Java is enabled globally and S1 disables it WITH the Admin credential, then Java is disabled globally, even for the Admin account. This behavior is as spec'd. Of course the bug is that the behavior of the UI is incorrect (S1 should not be able to enable Java for themselves), but the behavior of the plugin seems to be correct (if you disable via the Admin credentials, everyone is disabled). Note that we do not want separate controls for "system disable" vs. "per user disable" since most users are admins on their own systems so having two options will be confusing to the majority. The scenario outlined in this bug is, of course, an edge case, and the UI does not need to be optimized to make it easy.
29-05-2013
I'm assuming that in step 2, when user A disables the plugin he uses the admin credentials to disable globally, otherwise step 3 makes no sense. Also, is S1 a standard or admin user? I'm assuming standard and using user A's credentials to enable the plugin.
28-05-2013
This particular issue pertains to Mac OS X, which afaict seems to be working correctly in 7u25 b12. I've not been able to reproduce this issue yet, though I will wipe all traces of Java and try from a clean install to see if it makes a difference. I think the only missing part of the process is there's no clear indication of "system" versus "per-user" control in the UI until the plugin has actually been disabled, and then it's only reflected in the "only for this user" message appended to the control label. Perhaps there should be a separate option to disable for all users, if the admin privilege request is denied then that option fails entirely rather than falling back on per-user. This current model seems confusing and error-prone.
28-05-2013