Quick fixes not showing in custom code inspection result on hover

My plugin adds a large number of local inspections, most of them with quick fixes. Inspections in the core IDE include those quick fixes in the hover tooltip, e.g.:

image

However, I’m not seeing the same behavior for my plugin’s inspections with quick fixes:

image

Here’s the context actions menu showing the available quick fix that’s not included in the hover tooltip above:

image

I could swear that this used to happen automatically, but I just tested as far back as 2024.1 and see the same issue.

Is there something specific I need to do with the quick fixes I’m adding to ensure they’re included in places other than the context actions menu?

UPDATE: It seems that this is true for only some of my plugin’s inspections and not others. So far I can’t seem to find a clear pattern, but I’ll keep looking. Anyone who knows off the top of their head, please feel free to let me know. Thanks!

UPDATE 2: I think I’ve figured it out. If the quick fix returns a value from getName() that is HTML-formatted – and many(/most?) of mine do – that quick fix isn’t included in the hover tooltip. Is that expected? Is the only option “dumbing down” these getName() return values to be unformatted?

UPDATE 3: Here’s the issue in DaemonTooltipActionProvider#getFirstAvailableAction():

//we cannot properly render html inside the fix button fixes with html text
if (!XmlStringUtil.isWrappedInHtml(text)) {
  return action
}

I’ve actually implemented a semi-hackish way to make this work for both tooltip/unformatted and non-toolip/formatted requests…emphasis on the “hack”. But I’m going to move forward with it because I really like formatted quick fix labels when they can be used, but I also want these quick fixes to show up in tooltips. That’s worth the hack.

Out of curiosity, what does the hack look like?

I already have a utility method that can determine whether the caller stack includes a given class or class/method. I’ve needed it in the past for very specialized, tactical behavior based on a potential known caller, e.g., not having speed search in a combo-box stop cell editing as that was causing issues with a combo-box where final selection has a non-trivial cost to it but speed search is still exceptionally useful.

For this, I just check whether or not getName() or getFamilyName() is invoked from TooltipActionProvider, and if so, I use StringUtil#stripHtml() to remove HTML formatting from the resulting value. I already had a common base class for all of my LocalQuickFix implementations, so it was easily encapsulated there.

Like I said…it’s an ugly, embarrassing hack…but it allows for the desired behavior in both situations instead of requiring a least common denominator approach.

1 Like