[rfc][icedtea-web] Launching PolicyEditor from CertWarningPane

[Jiri Vanek]

Looks ok to go.


Few feature works
  - with only one item the submenu donot have much sense, but it will greow (? :) ) so ok if 
finished in 1.5.1

  -  the modality and filter needs to be fixed until 1.5
    - when there are already stored items in policies, the first one is selected, and user would 
like actually edit the *newly* added.  Probably not only filter, but be sure that the newly 
add/currnelty-should-be-edited item is really selected.

Please push the tweeks for attributevalidator as separate changeset and add trusted-only to news 
during commit please.


ty!

  J.
On 03/20/2014 08:57 PM, Andrew Azores wrote:
> On 03/20/2014 03:16 PM, Andrew Azores wrote:
>> On 03/20/2014 01:52 PM, Jiri Vanek wrote:
>>> On 03/14/2014 05:00 PM, Andrew Azores wrote:
>>>>> many import issues. Invaid(how comae? My wrong I guess) and especially unused imports.
>>>>>
>>>>> I gave up an code a bit O:). So user experience:
>>>>>
>>>>>
>>>>> popupmenu - best handling is NOT to add as component. And do not show them in actionPerforemd.
>>>>> Show them *without* parent, in mause Clicked - it have positionOnScreen, and you show the poup
>>>>> menu
>>>>> on this pposition. Should work like charm.
>>>>
>>>> This seems to work well, thanks for the tip.
>>>>
>>>>>
>>>>> I would excude this "V" from pproperties. Also the button s quote wide. Maybe use image rather?
>>>>
>>>> I tried using an image now but wasn't really happy with the results. I've changed it instead to
>>>> a unicode character that looks like the three horizontal line overflow menu icon that's being
>>>> used by iOS and Android. I think it's pretty nice although the button is still a bit wide.
>>>>
>>>>>
>>>>> Interesting state - dialog appeared , I clicked "V" clicked show policy editor, it apeared, I
>>>>> clicked cancel in mian dilog/or ok in main dialog.. The editro should be modal
>>>>
>>>> Hmm, well it's a JFrame, so I can't easily make it modal I don't think. Maybe as a separate
>>>> changeset PolicyEditor can be made into a JDialog and CertWarningPane can then be made to use it
>>>> as a modal dialog?
>>>>
>>>>>
>>>>> How does it behave for  yes/no/cancel/close of policy editor?
>>>>
>>>> The CertWarningPane doesn't know about this at all. All it knows about is if it has a
>>>> PolicyEditor reference, and if it does, if the editor is still open or has been closed.
>>>>
>>>>>    - small nit - other codebases in editor are confusing.
>>>>>
>>>>>
>>>>> Thanx!
>>>>>     J.
>>>>>
>>>>
>>>> I suppose, but PolicyEditor doesn't have any mechanism right now to display only one codebase
>>>> when there are also others present in the policy file.
>>>
>>> Then maybe it can be added? I think simple filter on shown list? And in this case the filter will
>>> be pre setup to show only new/edited codebase. This is also enough as next changeset (however...
>>> necessary....)
>>>
>>> Ugh .. the modality should be fixed :(.... Then maybe do it dialogue? This may be as another
>>> changeset, but should be fixed....
>>>
>>> Eg two containers - dialog an frame with same pannel.....
>>>
>>
>> Yes, both of these can/should be fixed, but as a different changeset I think.
>>
>>>
>>> Well one possible stop-show:
>>>
>>> geogebra do not start with :
>>> net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize
>>> application. The application has not been initialized, for more information execute javaws from
>>> the command line.     at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:789) at
>>> net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:529) at
>>> net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:911) Caused by:
>>> net.sourceforge.jnlp.LaunchException: The 'permissions' attribute is 'all-permissions' but
>>> security is' Sandbox'. This is fatal     at
>>> net.sourceforge.jnlp.runtime.ManifestsAttributesValidator.checkPermissionsAttribute(ManifestsAttributesValidator.java:145)
>>> at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:289)     at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:353) at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420) at
>>> net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:396) at
>>> net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:781) ... 2 more
>>>
>>> I think it is wrong. The run-in-sandbox should skip this check or otherwise handdle it.
>>>
>>>
>>> J.
>>
>> I've added a check in checkPermissionsAttribute to skip the check if the SecurityDelegate
>> indicates that the user has decided specifically to run the applet sandboxed.
>>
>> Thanks,
>>
>
> Tiny update, cleanly applies on new HEAD (with Trusted-only). Also threw in the one-line fix for
> Trusted-only and Sandbox.
>
> Thanks,
>