Check the native base of scripts when resolving icons

[YuriSizov]

See #80184 (comment). This is not a regression from #80184, though. The issue was present before as well, but it manifested differently:

The issue is that we only check the direct base class of script classes. This means that if your class extends another script class, we won't be able to find the fallback icon for it correctly. Before #80184 we would simply fall back onto the Node or Object, or whatever else was supplied as the common fallback icon. With #80184 the common fallback defaults to an empty string, so we end up with no icon whatsoever.

The fix is to find the first native base class instead of the direct base class and use its icon.

Fixes #79979.

---

PS. This PR touches code around the same lines as #81130, so it may lead to conflicts when one of them is merged. While this one is small and simple, I'd prefer #81130 to be merged first, if we're okay with it.

[akien-mga]

PS. This PR touches code around the same lines as #81130, so it may lead to conflicts when one of them is merged. While this one is small and simple, I'd prefer #81130 to be merged first, if we're okay with it.

This PR seems cherry-pickable, while rebasing on top of #81130 would make it incompatible with 4.1. So it may make more sense to merge the other way around?

[YuriSizov]

That's a good reason, yeah. It's just going to be slightly more annoying to rebase a large 3-commit PR, but I can manage :)

Note for cherry-picking, though, that it is based on #79203 (which may have caused this behavior, at least in its current form).

[akien-mga]

Note for cherry-picking, though, that it is based on #79203 (which may have caused this behavior, at least in its current form).

#79979 mentions 4.1.1-stable though. But I guess this fix depends on #79203 anyway?

[YuriSizov]

Yeah, the issue likely existed before, I vaguely remember it, but I didn't check. #79203 definitely changed where the affecting code resides and this PR changes the same part.

[akien-mga]

Alright, then I guess the order of merge isn't as important. I'm not sure the bug is problematic enough in 4.1 to warrant going out of our way for a custom backport. I guess it depends whether we do plan to cherry-pick #79203 or not.

[YuriSizov]

I guess it depends whether we do plan to cherry-pick #79203 or not.

I'd say yes, it's a point of a lot of confusion. Making a custom PR would be an easy option as well, it will take less time than our conversation here has taken so far 😛

[YuriSizov]

I need to rebase #81130 anyway now, so this is safe to merge once approved.

[akien-mga]

Looks fine to me, though I'm not an area expert.

[YuriSizov]

Thanks for reviews!

[YuriSizov]

Cherry-picked for 4.1.2.