Click sorting a views table with AJAX causes exposed filter settings to be lost

I've got a problem where clicking a table heading in a View to click-sort it causes any value that has already been set up in an exposed filter to be dropped. This means that click-sorting effectively returns the View to its default state with none of the user's filters selected - i.e. users can't sort after they've added a filter. The View is a Block View using AJAX, but I've tried with a Page view and discovered that the problem is specific to AJAX: a Page View with AJAX has the same symptoms, but a Page View without AJAX works perfectly.

The view is set up as follows:

• I have a content type with a CCK field of type "number", called Height.
• The View contains all nodes of this content type, and includes the Height field, which is set to be click-sortable (the view is formatted as a table).
• The View has an exposed filter on the CCK Height field, and the user is allowed to choose from all of the standard different ways of filtering numbers (>, >=, <, <=, ==, between, etc.)
• The View is a Block View, with AJAX enabled.

I've done some investigation into this, and discovered that the destination of the click-sortable link changes subtly when you attempt to click sort after a filter has been applied. It looks to me like it is being URL-encoded twice, which presumably means that Views can no longer decode it correctly, explaining why the exposed filter settings are lost. Unfortunately, I've never worked with the Views codebase before, so I've no idea where to continue with debugging this. If somebody could point me in the right direction, I'd be happy to try and debug further (bearing in mind that this is 6.x-2.16, which I guess isn't being worked on that much any more!)

When the page containing the block View is first loaded, the click-sortable Height link claims to have the following query string (obtained by cutting-and-pasting the link from the browser):
...?order=field_height_value&sort=desc&height_op=%3E%3D&height%5Bvalue%5D=&height%5Bmin%5D=&height%5Bmax%5D=
The relevant bit to look at is "&height%5Bvalue%5D=&", which, after URL-decoding, is saying that there is no value for "height[value]", as would be expected at this stage before applying a filter.

After applying a filter (e.g. height <= 10), the query string changes to:
...?order=field_height_value&sort=desc&height_op=%3C%3D&height%5Bvalue%5D=10&height%5Bmin%5D=&height%5Bmax%5D=&...
(additional Views stuff that has been appended is not shown). Again, the "&height%5Bvalue%5D=10&" looks sensible, claiming that height[value] should now be 10.

After clicking on the Height link to to reverse the click-sort, the filter is incorrectly removed, and all nodes are shown. The query string has now changed to:
...?order=field_height_value&sort=asc&js=1&height_op=%3C%3D&height%255Bvalue%255D=10&.......&height%5Bvalue%5D=&height%5Bmin%5D=&height%5Bmax%5D=
(where the dots in the middle represent the additional Views stuff that I removed before as well).

You can see now that we have "&height%255Bvalue%255D=10&", which has been double-URL-encoded, and so after URL decoding, gives "height%5Bvalue%5D=10", which I presume Views does not understand. It looks like Views has then thought it hasn't been given any value for height[value] (and other parameters with square brackets in them), and re-appended empty values to the end of the query string, which are correctly only URL-encoded once.

To me this shows exactly what the problem is, but, as I said, I'm not familiar enough with Views to know where to start looking for this. If anybody could point me in the right direction, telling me where the URL-decoding/encoding during AJAX processing occurs, I'd be happy to investigate further myself.