On Tue, 2 Dec 2025 11:06:32 GMT, Dmitry Drobotov <[email protected]> wrote:

> 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.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/28599

Reply via email to