<AWT Dev> RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application

Phil Race prr at openjdk.java.net
Fri May 7 19:58:39 UTC 2021


On Tue, 27 Apr 2021 07:08:58 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:

>> It is something of a new paradigm \(yes its been there since 10\.12\, 
>> that\'s not what I mean\) so
>> we should make sure its supportable\.
>> 
>> The system dialog UI talks of \"documents\" which might tell us something 
>> about the mindset
>> of the folks who designed it\. I also find it surprising it is a global 
>> system setting\.
>> It seems like something that is better set per\-application\. Of course if 
>> a Java runtime is used
>> for multiple applications that wouldn\'t help but it is moot for now so 
>> let\'s not spend time on that
>> 
>> It would be interesting to have an enumeration of known and suspected 
>> problems with this\.
>> \- where is it inappropriate UI \- if we have an unowned dialog it is 
>> really weird to popup it up in a new tab\.
>>  \?\? Are just at odds with the mac desktop where dialogs are always owned 
>> windows \?
>>  \?\?\? Do they imagine that all windows can layout nicely even if they 
>> don\'t get the size they want \?
>>  \?\?\? I\'m having trouble picturing how all this works smoothly
>> \- where do we have behavioural problems \- full screen oddities\, 
>> application freezes\, incorrect behaviour
>> of menu bars \.\. focus \.\.
>> \- what scenarios do we need to examine\? \?
>> 
>> I can imagine it would take some time to properly go through all of 
>> these and I think we should
>> schedule that rather than just disabling this and in all likelihood 
>> forgetting about this\.
>> Do we have a go\-with\-the disabling RFE to support it \?
>> 
>> If applications are freezing then disabling it might be an appropriate 
>> short term solution
>> We could consider a system property to prevent the disabling \.\. in case 
>> some one has an app where they\'d
>> really like to use it and understand the risks\.
>> 
>> Maybe new API is needed to make it supportable \- which would suggest to 
>> me that Apple made a mistake
>> in the way they implemented this\.
>> 
>> Probably this disabling is needed for older releases as new API won\'t 
>> make it back to those\.
>> 
>> 
>> \-phil\.
>> 
>> On 4\/10\/21 1\:30 PM\, Sergey Bylokhov wrote\:
>
>> It would be interesting to have an enumeration of known and suspected problems with this.
>> 
>> * where is it inappropriate UI - if we have an unowned dialog it is really weird to popup it up in a new tab.
>>   Are just at odds with the mac desktop where dialogs are always owned windows ?
> 
> Mac OS Alert opens up in new window no matter what the Prefer Tab setting is.
>>   Do they imagine that all windows can layout nicely even if they don't get the size they want ?
>>   I'm having trouble picturing how all this works smoothly
>> * where do we have behavioural problems - full screen oddities, application freezes, incorrect behaviour
>>   of menu bars .. focus ..
>> * what scenarios do we need to examine  ?
>> 
>> I can imagine it would take some time to properly go through all of these and I think we should
>> schedule that rather than just disabling this and in all likelihood forgetting about this.
>> Do we have a go-with-the disabling RFE to support it ?
> 
> I have filed a RFE for this : https://bugs.openjdk.java.net/browse/JDK-8266026.

@trebari where are we with my (off-line) suggestion to you that this fix be updated such that a System Property "-Djdk.allowTabbedWindows=true" be defined that lets someone over-ride the disabling so that folks can at least try out the effect of this on their apps whilst we figure out a supportable API ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3407


More information about the awt-dev mailing list