isActiveAndEnabled documentation was made inaccurate

This thread from me , and another thread from someone else, both encountered the same issue with isActiveAndEnabled returning false while active was true and enabled was true.

The current documentation states the following:

Reports whether a GameObject and its associated Behaviour is active and enabled.

So our threads were made because this statement was being fulfilled, yet false was being returned. I thought this was a Unity bug.

However in the discussion there, somebody pointed out that an older version of those docs stated the following:

Has the Behaviour had active and enabled called?

This makes clear that there is an additional requirement for the property to be true: that OnEnable is called.

Why was the documentation changed when the behaviour apparently remained? Should the documentation be updated again to clarify this additional requirement?

I have reported this previously. Here’s my bug report IN-27787 from 04/Jan/23, which was never made public on the bug tracker:

Here’s the response I got from Unity:

There’s a repeated problem here where bug reports for Unity’s software get a public tracking link and a voting system and you get an email when something’s done with it and everything, while documentation bugs go into a black hole and you never know if anything happens.

As an example of this being a problem, you and a bunch of other people has spent time and effort trying to figure out if this is a bug or not. If my bug report had gotten onto the actual bug tracker instead of being yeeted into the “we told the documentation team about it” void, you could have figured out that this was indeed a known problem instead of wasting time.

Or maybe nagging the docs team about it more would help? idk. if they’re reading the forums.

1 Like

Thanks for raising this! We’ve created an internal ticket and are looking into this now.

To Baste’s points, we do read the forums (at least the Documentation section). The most efficient way to log a documentation issue is to report an issue at the bottom of the relevant page. Those tickets do come directly to us, and we look at all of them.

You can see a small subset of some of the changes we made last month in our January documentation update .

Hi, Amanda!

I think it’s great that you’re making notifications of what you’re doing at the documentation team! The team has always been this mysterious entity that we always knew existed as other Unity employees told us that they forwarded stuff to the documentation team, but we have seen very little from you. So confirming that you’re working on stuff and showing it off is great.

That being said, I still think having a proper bug reporting system for documentation would benefit everyone greatly. I keep delivering proper bug reports because I get emails back saying “we’re looking at it, we fixed it, here’s the choices we made”, etc. I’m less inclined to log documentation issues because I have no idea what the rate of my reports to changes actually is.

So I think you would get more and better feedback, and happier users, if you either tracked the documentation bugs as normal bugs (which I honestly think they are), or if you had a similar system to the bug reports where we got an email about what happened to our issue.

1 Like

Hi, Baste.
You’re right that a two-way documentation bug reporting system would have benefits. For example, we would be able to more easily ask clarifying questions about bugs, and y’all would be able to track the status of the bugs you report. Of course, changing our feedback system depends on many factors. I’ve raised this topic for further discussion internally. If we make any changes, we’ll be sure to let y’all know.