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

Phil Race prr at openjdk.java.net
Sat Apr 10 23:24:28 UTC 2021


On Sat, 10 Apr 2021 20:27:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There is a larger issue here than just a freeze in full-screen mode. A user can set their "Prefer tabs" preference for opening documents to "Always" (rather than the default "in full screen") on either 10.15 or 11.0, and then all top level windows will open up in a tab unless they are child (owned) windows. This leads to a variety of unexpected behavior, which is why I think disabling it (as we did for JavaFX and as is proposed in this PR) is the best option. An application's windows are not always conceptually a set of related documents, so opening up all windows in tabs seems wrong.
>
>> There is a larger issue here than just a freeze in full-screen mode. A user can set their "Prefer tabs" preference for opening documents to "Always" (rather than the default "in full screen") on either 10.15 or 11.0, and then all top level windows will open up in a tab unless they are child (owned) windows.
> 
> Yes, I have tested that.
> 
>> This leads to a variety of unexpected behavior, which is why I think disabling it (as we did for JavaFX and as is proposed in this PR) is the best option. An application's windows are not always conceptually a set of related documents, so opening up all windows in tabs seems wrong.
> 
> All above are applicable to any applications and all frames/dialogs on the new macOS. For some reason, Apple decided this can be a good design. Why we do not try to fit in it? 
>  - We may try to configure the correct size when a few windows are merged to the same window
>  - We may try to fix a "hang" of some type of the windows
>  - And we may try to disable it for some type of the windows by creating "fake" owner.

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.

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

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


More information about the awt-dev mailing list