Sticker do not display properly

[NekoCaffeine]

I found that the UI element of the sticker intercepts click events and the drag and drop function works fine, but the whole element is completely transparent.

I see the following in the output at startup:

2021-08-29 05:17:55,713 [   1233]   WARN - tor.impl.FontFamilyServiceImpl - Couldn't access required runtime API, will fall back to basic logic of font selection
2021-08-29 05:17:56,510 [   2030]   WARN - rottled.doki.hax.HackComponent - Unable to hackSwitcherBorder for reasons.
2021-08-29 05:17:56,549 [   2069]   WARN - rottled.doki.hax.HackComponent - Unable to hackBookMarkBorder  for reasons.
2021-08-29 05:17:56,669 [   2189]   WARN - rottled.doki.hax.HackComponent - Unable to hackLivePreview for reasons.
2021-08-29 05:17:56,713 [   2233]   WARN - rottled.doki.hax.HackComponent - Unable to hackBookMarkBorder  for reasons.
2021-08-29 05:17:56,717 [   2237]   WARN - rottled.doki.hax.HackComponent - Unable to hackWelcomeScreen for reasons.
2021-08-29 05:17:56,748 [   2268]   WARN - rottled.doki.hax.HackComponent - Unable to hackLivePreview for reasons.
2021-08-29 05:17:56,758 [   2278]   WARN - rottled.doki.hax.HackComponent - Unable to hackSwitcherSelection for reasons.
2021-08-29 05:17:56,762 [   2282]   WARN - rottled.doki.hax.HackComponent - Unable to hackTipBorder for reasons.
2021-08-29 05:17:56,765 [   2285]   WARN - rottled.doki.hax.HackComponent - Unable to hackCaptionPanel for reasons.
2021-08-29 05:17:56,781 [   2301]   WARN - rottled.doki.hax.HackComponent - Unable to hackPopupBorder for reasons.
2021-08-29 05:17:56,785 [   2305]   WARN - rottled.doki.hax.HackComponent - Unable to hackStatusLineColor for reasons.
2021-08-29 05:17:56,787 [   2307]   WARN - rottled.doki.hax.HackComponent - Unable to hackColors for reasons.
2021-08-29 05:17:56,791 [   2311]   WARN - rottled.doki.hax.HackComponent - Unable to hackSdkComboBox for reasons.
2021-08-29 05:17:56,793 [   2313]   WARN - rottled.doki.hax.HackComponent - Unable to hackDebuggerAttributes for reasons.
2021-08-29 05:17:56,794 [   2314]   WARN - rottled.doki.hax.HackComponent - Unable to hackDebuggerAttributes for reasons.
2021-08-29 05:17:56,796 [   2316]   WARN - rottled.doki.hax.HackComponent - Unable to hackDebuggerAttributes for reasons.
2021-08-29 05:17:56,799 [   2319]   WARN - rottled.doki.hax.HackComponent - Unable to hackSwitcher for reasons.
2021-08-29 05:17:56,831 [   2351]   WARN - rottled.doki.hax.HackComponent - Unable to hackTitleFrame for reasons.
2021-08-29 05:17:56,835 [   2355]   WARN - rottled.doki.hax.HackComponent - Unable to hackTestResults for reasons.

IntelliJ IDEA 2021.2.1 (Community Edition)
Build #IC-212.5080.55, built on August 24, 2021
Runtime version: 16.0.1+9 amd64
VM: OpenJDK 64-Bit Server VM by AdoptOpenJDK
Windows 10 10.0
GC: Shenandoah Pauses, Shenandoah Cycles
Memory: 16384M
Cores: 32
Registry: ide.intellij.laf.enable.animation=true, debugger.watches.in.variables=false, ide.tooltip.initialDelay=0, ide.balloon.shadow.size=0
Non-Bundled Plugins: io.acari.DDLCTheme (18.0.0), amadeus.maho (212.5080.55)
Kotlin: 212-1.5.10-release-IJ5080.55

[Unthrottled]

I am fairly confident that the issue is due to you using

VM: OpenJDK 64-Bit Server VM by AdoptOpenJDK

As the runtime used by the IDE. For whatever reason the HTML rendering stuff acts weird in any runtime that isn't the bundled one provided by JetBrains.

I'll try to find some time later this week to investigate the issue.

[NekoCaffeine]

Yes, I also think it's a JRE version issue.

It may be that some of the javassist methods don't support that environment, but I need to know the details of the exception.

Is there a better way than build DLCC myself?

As my use case is rather extreme, I can accept a unilateral transform of bytecode in my environment to support DDLC's bytecode transformer after identifying the cause.

[NekoCaffeine]

By the way, this issue does not exist in IDEA-IC 212.3724.25 and the latest DDLCs supported by this version.

[Unthrottled]

It may be that some of the javassist methods don't support that environment, but I need to know the details of the exception.

Fairly confident that the issue does not have anything to do failed javassist message. Though, when I get the chance, I will test to see if not running them fixes the issue.

What you are saying is that the sticker does not show up, but there is a invisible pane that is still intercepting click events. Think that has something to with how the sticker pane is behaving. I'll have some time later this to try some things out.

[Unthrottled]

By the way, this issue does not exist in IDEA-IC 212.3724.25 and the latest DDLCs supported by this version.

So I assume that the sticker shows up in IC-212.5080.55 if you switch to the bundled runtime?

[NekoCaffeine]

Previous versions will call this (https://github.com/JetBrains/intellij-community/blob/3131c76023b8fc8baaf5d93108fc36ac22d85d82/platform/platform-impl/src/com/intellij/ui/jcef/HwFacadeHelper.java#L254) when jcef is not supported as a fallback.

But in an update (https://github.com/JetBrains/intellij-community/blob/3131c76023b8fc8baaf5d93108fc36ac22d85d82/platform/platform-impl/src/com/intellij/ui/jcef/HwFacadeHelper.java#L86-L107) this month, breaks this behaviour.

[NekoCaffeine]

When I insert fallback into the realization of current inaction, the behaviour is normal.

[Unthrottled]

When I insert fallback into the realization of current inaction, the behaviour is normal.

So I take it amadeus.maho (212.5080.55) allows you to do crazy things like overriding methods, such that you can provide your own implementation as a work around?

If so, do still want a fix? (Thanks for doing most of the investigation by the way!)

[NekoCaffeine]

So I take it amadeus.maho (212.5080.55) allows you to do crazy things like overriding methods, such that you can provide your own implementation as a work around?

Yes, my library can do a lot of black magic.

If so, do still want a fix? (Thanks for doing most of the investigation by the way!)

It doesn't seem to matter at the moment, and in any case I'm free from this problem for the time being. This should count as an IntelliJ issue.

You change the parent class from HwFacadeJPanel to JPanel if you wish to be OpenJDK compatible.

Also should I care about HackComponent's failure?

[Unthrottled]

Yes, my library can do a lot of black magic.

You change the parent class from HwFacadeJPanel to JPanel if you wish to be OpenJDK compatible.

I'll probably do something along the lines of that later, so will leave this open for the time being.

Also should I care about HackComponent's failure?

No, most of were created to change things like hard coded colors and stuff. I should probably go back and clean some of those up later in the future.

[NekoCaffeine]

By the way, if you have any doubts about Chinese, you can ask me.

[Unthrottled]

谢谢！我欢迎帮助，最近忙死了。现在我有事，以后可能会翻译。（写中文还是很难)

[Unthrottled]

Aight, I tried to plugin the java 16 open jdk into my intellij community, and it got very angry.

I'll assume that you got it to work by great feats of hacking. With that being the case, I'll close this issue, but if it comes back up in a future runtime upgrade, I'll keep this in mind.

Thanks for taking the time to share!

[NekoCaffeine]

@Unthrottled Yes, if you are interested, I would be happy to share the specific implementation and binary build with you. At present, I use a javaagent to make IntelliJ work normally on OpenJDK17.

And I also fixed two JDK bugs that caused IntelliJ to not run on JDK14 and higher. https://bugs-stage.openjdk.java.net/browse/JDK-8254975 https://bugs-stage.openjdk.java.net/browse/JDK-8270056

[Unthrottled]

At present, I use a javaagent to make IntelliJ work normally on OpenJDK17.

@NekoCaffeine That's some next level black magic. While I am impressed, I currently do not have the need use anything other than the bundled jetbrains runtime. If that changes, I imagine you'd share some 1337h4x :joy: