PHP: Ctrl + hover - freezing Netbeans (go to declaration)

[Eugene-Melbourne]

Apache NetBeans version

Apache NetBeans 19

What happened

I get methods header definition when I Ctrl + hover with mouse across a methods name in form of a tooltip.
Often, when I try doing it freezes the whole NetBeans and causes CPU use spikes up to 100% that can last for half a minute.

It is not functional in this form. Please, let me know how can I disable this feature until it is fixed.

How to reproduce

I have a large PHP project where I use a lot of third party packages, I guess it means that the project should be big.
The freezing is not happening every time, but it happens very often.
The important part is that you need to move mouse when pressed ctrl, if you first position a mouse and then just press ctrl - it will do "go to declaration". It is different and it is working fine.

Did this work correctly in an earlier version?

I have the same negative experience with all of the known versions of NetBeans as far as I can remember, 17/18/19...

Operating System

Windows 10 version 10.0 running on amd64; UTF-8; en_AU (nb)

JDK

19.0.1; Java HotSpot(TM) 64-Bit Server VM 19.0.1+10-21

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

I have a pretty good computer I7 with 32 GB of RAM. I don't believe scanning source texts would make this computer freeze even for one second unless there is a bug somewhere.

Please, let me know how can I disable this feature until it is fixed. Thank you

Are you willing to submit a pull request?

No

[mbien]

JDK 19 was a short term release and is end of life. You could try JDK 11 or 17 which are both long term support releases (NetBeans 20 will also support JDK 21 with is the latest LTS release). If you don't want to update the JDK all the time, NB is also available as bundle containing the latest supported JDK on the download page.

This might not help your issue, but at least the runtime is up to date :)

[Eugene-Melbourne]

Downgrade a JDK is a hack. I cannot afford breaking my environment experimenting with it at the moment.
JDK 21 is a Release Candidate just yet.

I think it is vital to have an option to disable this feature somewhere in the
Tools > Options > Keymap
or
Tools > Options > Editor > Code Completion

It is especially confusing that in the KeyMap we have "Wheel up" and "Wheel down" but we don't have "Right Click" and "Left Click". It looks like overlook to me

I suspect that the nature of this freezing is the overload of 2 features on the same condition "CTRL+hover":

1. the tooltip window with methods header definition
2. turning a text into a link that leads to the declaration

Thus, I believe the ability of disable each of these features separately would solve the freezing bug

[Eugene-Melbourne]

I just updated my Java to Java: 19.0.2; Java HotSpot(TM) 64-Bit Server VM 19.0.2+7-44
It still freezes the same way.

[mbien]

Downgrade a JDK is a hack

its no downgrade. JDK 19 is end of life.

JDK 21 is a Release Candidate just yet.

JDK 21 is released. However, it was released after NetBeans 19 so we couldn't support it at that time.

You can run NB 19 on the latest upgrade releases of following still supported JDKs: 11, 17, 20 as mentioned on the download page.

11 and 17 are long term support releases. NetBeans 20 will also support JDK 21 which is the next long term support release.

[Eugene-Melbourne]

There is another situation, that (I believe) is caused by this lack of a way to disable this feature.

<ctrl> + e - is a hotkey to delete a line of code, it is a light weight task, but when I press <ctrl> it activates the whole caboodle of functions related to mouse position such as - form a tooltip to turn and turning a text into a link.

So it freezes the whole system again for no reason, making combinations like (<ctrl> + e), (<ctrl> + x), (<ctrl> + c), (<ctrl> + v), (<ctrl> + z) vey annoying and even useless depending on where you mouse is resting at that moment of time.
Specifically <ctrl> + e is more affected then the others because I often do it with my left hand while moving mouse out of the way by my right hand. Or maybe <ctrl> + e makes the code to move under the steady mouse courser and the system considers it as a mouse hover.

I vividly remember having this <ctrl> + e issue on my previous work, which was more than 5 years ago.
It means that this issue cannot be fixed by installing older version of Java, version 17 is just 2 years old.
And It also means that this issue is coming from some legacy code. I remember there was a developer version back then that supported php7 and I used it because Netbeans-8 did not support php7.

[terax6669]

Yep, it has been an issue pretty much ever since I can remember (8.2 or 9), same with ctrl+space and ctrl+click. The infinite "background scanning" is gone, but the issue is not.

Excluding as many files from the project as you can as well as increasing the default cache/heap sizes used to help, but that's obviously only hiding the underlying issue... and nowadays I can't really tell the difference between increased cache size or not. Perhaps my current main project's size is just too large for it to make a difference anymore.

Personally I've gotten somewhat used to finding the class I need in the tab bar and using ctrl+f rather than ctrl+click, it's infinitely faster. And thanks to windows' win+v clipboard history I don't have to worry about copying the method name that I want to find 😅....

The sad fact is - if you want to work on big projects you gotta switch to PHP Storm. There have been bug reports, stack overflow threads, wiki articles (now available only on web archive due to the apache overtake) and no fix for 10 years.

[junichi11]

It would be nice if someone could provide an example project to reproduce it. That way, we can investigate it. Thanks.

[terax6669]

@junichi11
The project I'm working on isn't public, but I'm willing to send you a zip privately if you provide a way of contacting you directly.

[junichi11]

@terax6669 You can find my e-mail address in my commits.

[junichi11]

@terax6669 Thank you for providing it. I'll have a look at it later but I can't promise anything about resolving this.