[rfc][icedtea-web] headless dialogues -tech preview

[Jiri Vanek]

On 06/15/2015 02:38 PM, Jiri Vanek wrote:
> On 06/14/2015 08:04 PM, Jiri Vanek wrote:
>> Hi!
>>
>> the dialog subsytem in itw is wrong.
>> In last few and in a lot of future patches I'm trying to replace it.
>> When I was doing the remeberable solution, I noted that headless uspport is completly wrong, and no
>> worlaround may fix it.
>> Th eonly correct reaction is to print dialog to stdou, and request user to type answer. +1 from me,
>> her eis implementation :)
>> It consist 9again) from little bit more work, soI will push it in parts.
will be split:
  - replace system.exec by processbuilder for froking jvm and in xdesktopentry
  - extract System.getProperty("line.separator") to  method (in doPrivlidged - as it is now, it is 
causing errors wehn run in sandbox)
  - extract all "shouldPromptUser" to SecurityDialogMessageHandler
  - introduce fullsupport for headless dialogues
  - get rid of two pannels one in another
(-public class AppTrustWarningDialog extends SecurityDialogPanel {
  +public class AppTrustWarningDialog  {
(And in future, get rid of JDialog as base class for passing sthrough methods.  The Panel shold bne 
enough)

>> This patch add the headless logic, and have few advantages:
>>   - no aditional text hanling. The dialogs can prints themselves based on current ui!
>>   - no aditional input chekcing. With strong types, each can read itslef perfectly as it is already
>> done!
>>
>>   - it encapsualtes a lot of suplicated code - eg the if (!sahouldAskUser)...if (trustAll) ..
>> If9trustNone).,... and more. So there is much more removed code then added :)
>>
>>
>> So the patch itself is quite good, isnt it? :)
>>
>> Few drawbacks
>>   - stdin get broken if underlying application creates new VM. Currently I dont know how to
>> workaround it. But it may be surviable.
>
> ok.It is caused by:
> http://icedtea.classpath.org/hg/icedtea-web/annotate/cedb9509df43/netx/net/sourceforge/jnlp/Launcher.java#l440

Repalcing System.exec by processbuilder and arranging proper stream redirection solved this issue.
>
>
> I was blind to overlook it - but *why* it is here? It is from original netx, and mentioned in all
> docs.... whyy???
>
>>   - it do nto work without X....
>>
>>
>> yah the last sentence is pitfall. It is casued by EVERYTHING in itw expects SecurityDialogue to be
>> existing. And new Window() is on the blacklist in headless mode.
>> But I have some ideas how to ix it....
>>
>>
>> J.
>
> Also in this patch is bug:
>
> +           if (!shouldPromptUser()) {
> +                message.userResponse =  dialog.getDefaultPositiveAnswer();
> +                unlockMessagesClient(message);
> +            } else if (isHeadless()) {
> ...
> But it should be :
> +           if (!shouldPromptUser()) {
> +                message.userResponse =  dialog.getDefaultNegativeAnswer();
> +                unlockMessagesClient(message);
> +            } else if (isHeadless()) {
>
> "getDefaultNegativeAnswer" of course ....

Also fixed
>
>
> J.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: headlessDialogues2.patch
Type: text/x-patch
Size: 60236 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20150615/3e32bbe5/headlessDialogues2-0001.patch>