@brianteeman As stated in the title it's a J4 issue not J3.

(sorry - fat fingers - now fixed)

I found an easier way to test. Use the Plugins list. Edited above.

@schnuti is this reproducible in J 3.x as well?

Explanation

The Model code is the same

But model 's code for populateState() for both J3 and J4 does:

...
$limit =0;
...
Loop through posted data and set model's state
  and inside there it has:
...
			case 'limit':
				$value = $inputFilter->clean($value, 'int');
				$limit = $value;
				break;
...

Thus if you do not post the a list[limit]
(this is what is different in J4, the clear button does not post list[limit]) (in j3 it is posted)
Then $limit = 0; remains unchanged

• and then the query runs without limit and you get ALL rows listed !!

... and the list[limit] selector since no value was given it loads with default value from XML which is 25 (you do not get the limit from configuration since model's state was set 0 as explained above)

Could we use sessionStorage somehow? I mean try to keep the state in the client side

hhmm,

• we already using 'list.limit' from session, right ?

i mean 'list.limit' and -all filters- values are used from session when the listing view of the managers is opened (i mean re-navigated to)

but when listing view of the manager is the result of a posted form then model code has the assumption that any-non posted (filter) values need to be cleared (because they are filters !!)

model is treating the list.limit as filter (and usually filters do not have default values!!) aka we are not setting them to anything, but this is wrong because limit has a default value

My suggestion for a fix is do both of these

1. do J3 approach and post it [EDIT] (or get it from session) , thus keeping the current user value
2. Furthermore fix the model too in the case that for whatever reason it is not posted , set it to its 's default value from configuration before the loop that sets the filters

aka instead of:
$limit = 0;
do
$limit = $app->get('list_limit');

Please note that the above will not break
list limit "ALL" (aka all rows listing) because in that case you have a posted value , the value '0'

Or you can just do point 2 and not post the value, and every time you click clear you go back to configuration default

I would prefer to keep the J3 behaviour. Do not clear list limit and not list order only the filters. I see a difference and the sorting and the list limit should really be kept as set by the user.
I guess removing this from the JS should fix the problem.

The filters were more separated from ordering and list limit in the J3 UI but the new Table Options button do not have to change the behaviour of the Clear button.

@dgrammatiko
This seem to solve the issue.

		if (!self.clearListOptions) {
			self.getListFields().forEach(function(i) {
				i.value = null;
				self.checkFilter(i);

1. Note the ! Not clear the list data.
2. The null value prevents data from being sent.
3. The data used in the php model comes then from the session. (user set or default)

I made this in a J4 version a few weeks okd. In a later version the JS has changed and the CSS classes seem to be out of sync with the JS and harder to change. The list fields are included in the filter fields or something like that.

@schnuti Do you think you could have another go at fixing this?

@brianteeman
I'm not a Javascript guru but I'll have a new look. I hope I still remember some of my findings. I would prefer not to clear ordering and number of items as those are not filters (see J3). The Javascript also tries to set a fixed number (20 I think) and not according to the Global Parameter setting. Personally I never want to clear the ordering just because the filters are changed or cleared. As I remember a HTML-class has to be added for this but would solve this issue.

@brianteeman
I think I have a quick and dirty solution = less work. I already find the merge of the list-container (ordering + No items) into the filters-container was a bit quick and dirty. More in the PR.

PR #25697 is good, I've just tested with success. One more tester please ?

@schnuti Can this issue be closed now as your PR is ready? Or is there something left to be done?

Set to "closed" on behalf of @alikon by The JTracker Application at issues.joomla.org/joomla-cms/21676

please test #25697