This PR fixes the crash that was happening if either `axComponent` or `currentElement` had null values, by returning `nil` early instead of doing null dereference. Additionally, I've added missing `CHECK_EXCEPTION()` after the JNI call and a clean-up of `axComponent` variable, but these 2 changes are unrelated to the crash.
#### More details about the crash It reproduced in IntelliJ IDEA when using one of accessibility tools (such as VoiceOver, Voice Control, Zoom, Full Keyboard Access) and interacting with combo boxes that had popups based on `JPopupMenu`. The first interaction with the popup was good, but if there was a GC run before the next popup opening, it would crash on open. What happened was that right before the crash, in `MenuAccessibility` at the point of calling ``` jobject axComponent = (*env)->CallStaticObjectMethod(env, sjc_CAccessibility, sjm_getCurrentAccessiblePopupMenu, fAccessible, fComponent); Both `fAccessible` and `fComponent` are not null. But on the Java side, in `CAccessibility.getCurrentAccessiblePopupMenu(Accessible a, Component c)`, `c` would be null. `fComponent` is created by `NewWeakGlobalRef`, so this scenario is possible. This results in `axComponent` being `NULL`, and then `currentElement` will also have `nil` value. After that, when calling `[CommonComponentAccessibility childrenOfParent:currentElement]`, in the line `if (parent->fAccessible == NULL) return nil;`, `parent` is `nil`, so it crashes. Returning `nil` in `accessibilityChildren` is acceptable and would make VoiceOver say "menu (0 items)", but otherwise it will work with menu items normally. There is another issue that we even end up in the state when `fComponent` peer is not updated after GC, or that `MenuAccessibility` is not recreated after that. But I haven't investigated that yet and not sure why exactly it happens. I believe for now it's good enough to add these checks on `accessibilityChildren` level. #### Testing I wasn't able to come up with a test case using simple Swing components that would capture this regression. It's very likely that the reason it was reproducing in IntelliJ was related to our custom components or other parts of our setup, and it's hard to pinpoint the specific cause. I did check `TestPopupMenuChildCount` and there were no changes to VoiceOver announcements. I also couldn't reproduce the crash in IntelliJ when using the OpenJDK build with the fix. ------------- Commit messages: - 8372757: MacOS, Accessibility: Crash in [MenuAccessibility accessibilityChildren] after JDK-8341311 Changes: https://git.openjdk.org/jdk/pull/28599/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28599&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372757 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28599.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28599/head:pull/28599 PR: https://git.openjdk.org/jdk/pull/28599
