From LaughingPanda

Debugging doesn't work right any more if the default editor is Wicket Editor. While debugging the line of code that is executed by a thread is not shown in the editor window anymore.

Yes, this is a known bug. It is not possible to fix this easily in current eclipse versions. We have reported the issue to eclipse devs and the only news we've got from them is that they wont fix it in 3.3. Let's hope it will be fixed at some point, though! A workaround is to set normal Java editor as a default editor when debugging (files opened with wicket editor must be closed too before debug session starts).

When using "Open With" do not click the option that sets the Wicket Editor as the default. I have not verified the following in the code, but the behavior seems to be that this makes the wicket editor the default editor for all Java files. The Wicket editor then looks to see if the file is a Wicket file and if not, then hands the file off to the Java editor. In the process, the context has been lost. The result is that if you had ctrl-clicked on a method, that info is lost, so the page is opened but the cursor is not placed on the method. My workaround is to never let Wicket be the default editor. Eclipse will remember if you've opened a file with the wicket editor and use it the next time, so you do not need to set it as the default. - Curtis Cooley

Wicket Bench crashes with an SWT-Error when trying to use browser specified with MOZILLA_FIVE_HOME?

Firefox can be used with SWT 3.1 (Linux only), provided that it has been compiled with linkable Gecko libraries. It is important to note that Firefox downloads from mozilla.org currently do not satisfy this criteria, but Firefox installations that are included in major Linux distributions typically do. Attempting to use a statically-linked Firefox install will display the error message "No more handles [NS_InitEmbedding...error -2147221164]".