@cppl can you add testinstructions maybe also for non-developer? I'm not sure how to test.

Like: Bevor patch use this code you get this result ..., after the patch you get...

It's a subtle problem, previously 'safehtml' would be treated as a string and be decode, processed for XSS and have black listed tags removed against the user profile setting (Super Users are usually not filtered at all).

String's (aka default case) are _decoded first, then run through _remove to remove XSS, blacklisted tags etc.

SafeHTML (aka html case) is firstly cast as string then it's run through remove, there is no _decode done, which I think is correct for HTML, only the removal of black listed tags etc should be done.

I only found it through an odd bit of code for a clients custom integration, which unfortunately I can't share.

p.s. this also exists in 2.5.x.

I've done some tests here on my system and I can at least say that you are not wrong, but I don't know if you are right. sigh I most likely did something wrong, so here is my test-setup and my results:
I simply wrote my own code into the root index.php of Joomla to var_dump() the content of my URL variable "test" and also dumped what JRequest::get('request') returned. When I have ?test=<h1></h1><iframe></iframe> as my URL, I only get empty strings in those cases for "test". When I access $_REQUEST directly, I get <h1></h1><iframe></iframe> for test. If I then send that through JFilterInput however, I always get only <h1></h1>, which would be correctly filtered, but it does not make a difference between string and html filtering...

So, to be honest, I don't see a difference between the two (yet). At the same time, I'm pretty sure that you are right and that this is a mistake at the moment... I would go as far as saying that "string" most likely does not filter enough right now. Should "string" not clean all HTML from the string?

I have to say that I hate this filterclass, since I wasted 2 days a few years ago to go through them to find a bug and understand them at all. I'm pretty sure that there is a hidden security issue somewhere in there...

after this patch <field filter="safehtml" /> and <field filter="html" /> will have same behaviours, but should be difference , or I am wrong?

hm, I wrong, there is different behavior

@hackwar You only tested the JInputFilter class. This PR doesn't touch that one. It would change the behaviour of a form using a SAFEHTML filter in a form.
The only form I found which uses that is https://github.com/joomla/joomla-cms/blob/staging/components/com_tags/views/tags/tmpl/default.xml#L61 which is the menu item form for "Tags" -> "List of all Tags". There you have the "Heading Description" in the "Options" tab which uses that filter.

I want to make clear that what this PR changes is the way JFIlterInput is called in JForm. So my comment does in fact adress the issue in this PR.

I'm merging this on review

Any supplementary changes to consider for:
https://github.com/joomla/joomla-cms/blob/staging/libraries/legacy/request/request.php#L545
?