Views argument set incorrectly when using AJAX pagination and a path alias

Problem/Motivation

I think the approach that the views AJAX system takes to determine views arguments is incorrect. Right now when doing AJAX pagination, the view attempts to get all of the contextual view information from the pager link. If ?page=1 is set on the link, it will use that in it's ajax request. If /VIEW-PATH/arg1/arg2/arg3 is set, it will use those three arguments when executing the view.

This makes sense for query strings because they are never aliased and are required to store the pagination state. The problem with arguments is that all of the argument plugins that load context are aware of the underlying route. For example, when a views block is attached to /user/1 (aliased to /member/admin), the plugins can successfully determine that the view needs to be filtered by user id 1.

When an AJAX pagination link is clicked, the arguments are attempted to be determined from the HREF of the link. This is done on the client and has no knowledge of being able to pull an argument value from a route. The result is /member/admin is parsed and "admin" is determined as the argument for the view. Once this filters through to executing the view, the context of this being an entity ID that can be filtered with is lost and the view returns 0 results.

I don't believe we can successfully parse a views arguments on the client without the routing context.

Proposed resolution

When paginating, don't recalculate the views arguments based on the link HREF. Use the same arguments that were present when the view loads.

I believe this makes sense because it's unlikely you would ever want arguments to change between pages.

Remaining tasks

Validate/patch/test.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.