When clicked on Jump to structure definition... on member access field and Local Types window is not open - IDA just opens the said window without actually jumping.
Local Types window has to be open for the context menu action to do what it’s supposed to do.
Thank you for the report. I’ve just tried on a random sample but could not reproduce the problem (on Windows), so I expect there is something I’m doing differently, or it is somehow specific to your sample or macOS(?).
Can you reproduce it on other platforms? If so, could you please file an issue on support.hex-rays.com with a sample IDB and the exact steps you’re performing (clicks/keypresses, menu items etc.)? The screencast is already useful, but it doesn’t give the whole picture.
P.S. please also mention if you observe a difference in behavior when using the context menu vs shortcut (Z).
Confirm this bug as very annoying and often, still reproducible on any database with big number of local types, on IDA 9.3 too, on any platform (Mac, Windows, Linux: same behavior)
Pressing shortcut ‘z’ on structure field in pseudocode often (not always) jumps to wrong position of “Local Types”. If switch back to pseudocode, and try ‘z’ again - jump to correct position.
Cannot share IDB, sorry.
I had this issue with every IDB, so it doesn’t seem related to the number of types in the database in my case. Both the context menu action and the Z shortcut trigger the same bug.
Just a thought: I’m not sure how this is implemented internally, but I ran into something similar when developing a plugin with Qt. I needed to trigger a second action after a UI element became visible. I solved it using a QTimer::singleShot with a short delay. The sequence was:
Click button → open UI element + start single-shot timer → when the timer ran out, run the second action (e.g., jump to member).
If the delay was too short, the UI element would appear, but the second action wouldn’t do anything because the window wasn’t fully ready when the timer ran out. Since my computer is kinda slow, it takes a bit more time for the UI to become ready — longer than the timer delay.
Since @bes mentioned this only happens when the IDB has a lot of types (although for me it happens in every IDB - slower machine), it makes me think this could be said timing issue — the second action (jump to member) might run before the Local Types window is completely ready.
EDIT:
My understanding could be wrong, but the call to callui(ui_open_builtin2, BWN_TITREE, ordinal, &cursor) eventually reaches another function that checks !strcmp(..., "Local Types") and calls get_module_data(...) . That function determines whether the Local Types window already exists, sets an out-parameter flag accordingly and creates the window if neccesary. However, when the window doesn’t exist, the flag is set to 1 early and never updated after the window is successfully created. The caller then sees the flag as 1 and skips the jump to member logic entirely. Ignoring the flag altogether in caller function solves the issue. Hope that helps.