Imho, it's used in edit forms.
I agree fully that it should be loaded there in the layout file instead of the content.php. Allowing it to be overriden by the template if it's not needed and only be loaded if it's indeed needed.

Actually, it's never used in com_content edit forms in the frontend (see the previous discussion on Joomlacode).

Actually, it's never used in com_content edit forms in the frontend (see the previous discussion on Joomlacode).

The edit form has tabs and if you have an error in the form (like a missing title), it will reload the page. with the same tab activated.
JoomlaCode is wrong

In that case I suppose some questions would be:
1. If the Title is missing, would one want to be in a "wrong" tab upon reload?
2. Can any of the fields in tabs other than the first one generate an error?
3. Is the tab-state behavior even desirable in the frontend?

My personal opinion on those questions:
1. No. :)
2. Possibly, but the only ones I've found are the date/time fields. If they are incorrectly formatted Joomla throws an HTTP 500 Internal Server Error and doesn't reload the form.
3. In the backend where the user presses Save and expects to be able to continue editing where they left off it makes perfect sense. But in the frontend where "Save" really means "Save and Close", I am less inclined to think so.

In the case of an error, of course the ideal behavior would be to activate the tab where the error occurred. Seeing as a missing Title is probably the most likely error, the tab-state script currently prevents this ideal behavior.

The missing title was an example. There could probably be other errors in the form which end up in a reload. And yes, it is desirable that it's loaded with the same active tab, otherwise it's confusing.
The user will be prompted with an error message, so he will know what is missing.
I don't see a reason why we would want to remove that function, taking away a working feature within a major series is never an option.

So please update your PR and move the tabs-state call to the edit form layout(s). This way it's possible to override it in a template and you can remove it there if you wish to.

Alright, PR updated. :)

thanks

RTC

Tested. It works fine.

Could this be included in the upcoming 3.3 release?

Could this be included in the upcoming 3.3 release?

Merged into staging, thus it will be in 3.2.4 and 3.3.0.
Thanks!

Great! :)