Issues with MediathekView

[bb]

Describe the bug

Disclaimer: While I noticed an issue with MediathekView, I didn't see the connection to AltTab by myself.

MediathekView is a movie downloading app written in Java. Both on their Release Website as well as their Changelog they mention issues with AltTab:

German original:

ACHTUNG(macOS): Die Verwendung des Programms "AltTab" führt zu häufigen Programmfehler wie Einfrieren/Abstürze,etc. Es wird dringend davon abgeraten MediathekView und AltTab gleichzeitig zu betreiben

Verbatim translation (by me):

Attention (macOS): Using the program "AltTab" leads to frequent application errors like freezing/crashing/etc. It's strongly discouraged to use MediathekView and AltTab at the same time.

I'm a very happy AltTab user and I especially noticed the frequent releases and great responsiveness of @lwouis regarding any kind of issues which arose in the past. Thanks again for that.
So I think it's a pity there's public blaming of this great app but no (publicly visible) communication in either project.

Steps to reproduce the bug

1. Have AltTab running (as I have all the time ;-) )
2. Open MediathekView and trigger some downloads. (No worries, it's tax(-like)-funded public German/Austrian TV, not commercial films)
3. Leave to dinner (or whatever, so screensaver will turn on).
4. Return to the computer later and observe everything is running fine, except MediathekView being frozen and showing a spinning beachball of death while being hovered. It was not freezing at first within the first 5-or-so minutes but very quickly at subsequent runs. It continued working normally (after killing and restarting) when AltTab was not running.

Honestly, this all sounds like an issue in MediathekView (which is still frozen while I'm writing this and remains frozen when manually quitting AltTab) and not in AltTab (which continues to work fine), but obviously, there's a connection.

Maybe those easily reproducible issues crashes can unveil some special care which needs to be taken for MediathekView or even Java apps in general?

[lwouis]

Hi @bb! Thanks for sharing this issue, and for the kind words!

I was able to reproduce the issue with even simpler steps:

• Open MediathekView
• Click the Merkliste verwalten button in the top toolbar:
  
• The app freezes (only if AltTab is running in the background)

The issue is similar to #813. So I encourage you to look at this issue, and the issues mentioned in it to get a better understanding of what's at play here.

I could hardcode an exception for MediathekView, like I did for a few other apps. However, MediathekView seems to use some off-the-shelf system to package their mac app, and their bundleID was com.install4j.2884-1958-5872-3865.59 in my tests. It seems like it could be unstable over time, like maybe change on every release for example. It also seems like I wouldn't be able to match with "it starts with com.install4j." because that could be another app using this Install4J framework.

Wow I only realized now for some reason that all the apps exhibiting the issue: Jetbrains apps, Protege, Live2D Cube Editor, and MediathekView, are all Java apps. That could hint at a JDK bug. I guessed in the past that it was likely a macOS bug, which it still can be, but it's probable that it's a bug in the JavaFX/Swing framework, where they incorrectly deal with OS events/interactions.

I'll try to see what happens in MediathekView source code when I press the Merkliste verwalten button while AltTab is running in the background. Maybe I can get a clue.

It would be very helpful if you opened a ticket on their side as well, explaining this context, so that they can also reproduce the steps above, and debug their app to understand why it freezes.

[lwouis]

The app seems to freeze on this line:

Note how the method docs say "Be very careful with this because this can cause deadlocks." Seems to me like it is indeed deadlocking here, which is why the UI is unresponsive and we see the spinning wheel cursor.

Now how AltTab is interacting here is pretty unclear to me.

When I pause the debugger while the app is frozen, I see it's stopped here:

Looking at the call-stack:

We see MediathekView > JavaFX > Glass UI > AWT > Interaction with the native OS (in our case, macOS RunLoop)

I think the best bet is that it's an issue in JavaFX. I searched on their ticket tracker, and found this issue which seems to be exactly the issue we are seeing in our case. The issue was closed after a while without being actually dealt with.

[lwouis]

I can't open a ticket or comment on the openjdk website. They suggest on their wiki to report on bugreport.java.com, so I did. I wrote a very detailed and documented ticket, and got this message at the end:

[bb]

Hi @lwouis,
thanks for this in-depth investigation! You again overfulfilled my expectations. 😊

I created mediathekview/MediathekView#592 (including asking for a stable bundle id) and also gave a look at the OpenJDK bug tracker. I don't have an account either and also don't see a way to create one.

I wonder if JavaFX apps could be blacklisted not by their bundle id but e.g. by e.g. having a ClassPath defined in their Info.plist or .jar files somewhere within their app bundle? Of course, that's just a hacky work around, but maybe more efficient than trying to collect all bundle IDs of java apps?

[derreisende77]

Hi @lwouis!

I am the developer of MediathekView. You should be able to blacklist MediathekView based on the BundleID. The 2884-1958-5872-3865 part is a unique id from install4j that got generated when the project got created. I also have no plans on changing this in the future. It is also available as i4j.appId property in the Info.plist.

Wow I only realized now for some reason that all the apps exhibiting the issue: Jetbrains apps, Protege, Live2D Cube Editor, and MediathekView, are all Java apps. That could hint at a JDK bug. I guessed in the past that it was likely a macOS bug, which it still can be, but it's probable that it's a bug in the JavaFX/Swing framework, where they incorrectly deal with OS events/interactions.

The macOS java graphics pipeline sometimes behaves entirely different/erratic to the ones on windows and linux and the reasons are (at least for me) impossible to debug as they are buried deep within the native code they wrote. But I do think that the problems from my POV are caused primarily by the graphics implementation in the macOS JVM. We have a lot of problems with UI code written e.g. on windows malfunctioning on macOS. But I gave up trying to report bugs to Oracle/whoever as they do not care.

JavaFxUtils.invokeInFxThreadAndWaitis not the only function that will go crazy in the presence of AltTab. I basically gave up debugging why existing UI code that was working correctly for ages suddenly behaved entirely erratic. Calling JavaFxUtils.invokeInFxThreadAndWait just gives an almost 100% deadlock guarantee in presence of AltTab, but it sometimes fails as well without on macOS, but not in Linux and Windows. That´s why I left the deadlock warning in the comment as code with this call MUST be tested carefully on all 3 platforms.

The presence of AltTab causes real damage to the application data and logic therefore I issued a warning against using it - although I really liked AltTab but it caused for me more pain than pleasure when using it with my Java dev environment :(

[lwouis]

Thanks @bb and @derreisende77 for a very pleasant investigation and discussion! Here is a synthesis after reading all the material you provided.

First of all, I'll hardcode an exception for MediathekView in AltTab, so that we mitigate the issue quickly. I'll use the bundleID since it's stable. It's important to note that while AltTab will stop being an issue, other accessibility apps will probably still create the same issues.

Regarding Oracle not dealing with tickets, I understand. It took me 20 minutes just to understand how I was supposed to report the issue. I could guess they don't welcome general-public feedback, and that it's probably a walled-garden ecosystem where only corporate members are listened to.

I wonder if JavaFX apps could be blacklisted not by their bundle id but e.g. by e.g. having a ClassPath defined in their Info.plist or .jar files somewhere within their app bundle? Of course, that's just a hacky work around, but maybe more efficient than trying to collect all bundle IDs of java apps?

The idea of ignoring all java apps is interesting. However, some apps may actually use native macOS tabs. I imagine it's possible even through Java UI frameworks to use those. It's not typically used I believe, but I wouldn't want to fail detecting tabs on a Java app because I ignored it on all Java apps in a blanket policy. I think for now hardcoding each app that exhibits a problem (and has enough users that a few open a ticket here) is acceptable.

[derreisende77]

The com.install4j. part usually comes from a generated native launcher wrapper for macOS Java UI apps. IMHO it may be good to exempt those apps entirely as they may exhibit the same problems like other java apps.

The idea of ignoring all java apps is interesting.

I would not attempt to do that. Cyberduck for example is a java app that uses Cocoa API via java bindings for the UI. Although it is (primarily) written in Java it should not exhibit the problems Swing/JavaFX apps have. But I haven´t tested it.

[lwouis]

The com.install4j. part usually comes from a generated native launcher wrapper for macOS Java UI apps. IMHO it may be good to exempt those apps entirely as they may exhibit the same problems like other java apps.

As I said, a drawback of this is that if one of those apps use native macOS tabs, then AltTab will fail to follow these. It's a trade-off between potentially breaking some apps (it's not clear that all JavaFX apps break for instance. It seems to happen in specific cases / code flows / apps) vs potentially incorrectly detecting native tabs in these apps.

[bb]

Thank you both for all your work on that! I'm sorry to hear about all those issues regarding communication with Oracle. This is a good testament to give Oracle a wide berth.

@derreisende77, if you use other apps which you know have problems when AltTab is active, maybe you can provide us with a list of bundle ids here, so they can be included in the black list? This way you and others could again enjoy AltTab.

[lwouis]

@bb note that I added the workaround for the whole com.install4j.* pattern instead of just the specific ID of MV. I think you are right that the tradeoff is more interesting that way

[derreisende77]

I can confirm the App Bundle version of MediathekView works. However when launched manually Java still freezes as there is only a java process without the blacklisted bundle id.
May be in a future version it would be great to disable AltTab based on the java process name. Otherwise for example I cannot debug the app with IntelliJ

[lwouis]

Dear Java Developer,
We have finished evaluating your report and have assigned it a Bug ID: JDK-8262292. The issue is visible on bugs.java.com at the following url JDK-8262292.

https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8262292

[derreisende77]

As I said you can save the time writing bug reports for them... :( Linked to another bug which is open since 2018