Avoid obsolete filter syncing #7135
Conversation
That appears to be obsolete as the filter is anyways sent to the @ClientCallable method when the filtering should actually be done.
|
|
One failed test. Which is kind of more a timing issue. In a mode when the popup is configured NOT to be automatically openend, the previous test triggered the filtering more eagerly. Don't know what would be the "correct" behaviour if #6863 gets fixex. Could be fixed either by adding a wait/timeout to the IT or to keep syncing the filter also via event, but make that lazy. Or changing client side so taht by making open event also contain the filter or so that connector calls some method instead (like it does with regular filtering). |
|
Let's consider combining this PR with #7133 so that the context is available in one place. We should also proceed with adding tests. @mstahv, would you be able to add tests, or would you like us to handle them? Also, please specify your compilation issues so we can help resolve them. It might be potentially a small breaking change, since |
|
I'd keep these separatly. This is more like a bugfix or performance improveiment and the other is technically "a feature", so it will probably be require a minor version (and now that 24.7 was just "closed", it will take a looong time). Would be great if you can tackle the possible new tests. As I don't work with selenium daily, I don't have good ideas to how to automatically assert extra requests are made. |
That appears to be obsolete as the filter is anyways sent to the @ClientCallable method when the filtering should actually be done. After this change there is a lot less XHRs/server-visits happening aka reduces "chattiness" (although there still is some that I don't really know what they are related to (opened changed and some "confirm" requests).
Opening as draft as somebody involved in the current implementation really should look into this (and couldn't run the tests locally).
See also #6863 and #7133