fix: Use ButtonWrapper for pagination buttons

[gethinwebster]

Description

Pagination's page-button finders returned ElementWrapper, so consumers couldn't call isDisabled() — the buttons use aria-disabled rather than the native disabled attribute (see #4576). This adds a pagination-scoped PaginationButtonWrapper (exposing isDisabled()) and returns it from findPreviousPageButton, findNextPageButton, findPageNumberByIndex, findCurrentPage, and findPageNumbers. Pagination renders bare <button>s rather than the Button component, so a dedicated wrapper is used instead of reusing ButtonWrapper (findJumpToPageButton still returns ButtonWrapper, as it wraps an actual Button). Non-breaking, since PaginationButtonWrapper extends ElementWrapper.

How has this been tested?

Updated the pagination tests to assert disabled state via isDisabled(), and added prev/next focus-retention tests (#4576 switched to aria-disabled to keep focus but shipped without a test for it).

[avinashbot]

Note: pagination renders bare elements rather than the Button component, so ButtonWrapper methods that depend on Button-component internals (findLoadingIndicator, findTextRegion, findDisabledReason) are not meaningful for pagination buttons. The commonly needed methods (isDisabled, click, getElement, keyboard/focus helpers) all work.

Doesn't this seem brittle? It seems like a sensible assumption for a Cloudscape dev that component wrapper classes only map to the components exactly, so this might subtly break in the future, especially for methods that we don't test.

This is definitely prettier than my idea though (#4673). Do you think a new "NativeButtonWrapper" that ButtonWrapper could extend from could be possible?

[gethinwebster]

Note: pagination renders bare elements rather than the Button component, so ButtonWrapper methods that depend on Button-component internals (findLoadingIndicator, findTextRegion, findDisabledReason) are not meaningful for pagination buttons. The commonly needed methods (isDisabled, click, getElement, keyboard/focus helpers) all work.

Doesn't this seem brittle? It seems like a sensible assumption for a Cloudscape dev that component wrapper classes only map to the components exactly, so this might subtly break in the future, especially for methods that we don't test.

This is definitely prettier than my idea though (#4673). Do you think a new "NativeButtonWrapper" that ButtonWrapper could extend from could be possible?

oh interesting, I'd not realized we use plain <button> and not even here. Yes, in that case I agree it's not the best solution, will update it.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.57%. Comparing base (45502c0) to head (e8031a1).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4698   +/-   ##
=======================================
  Coverage   97.57%   97.57%           
=======================================
  Files         948      948           
  Lines       30507    30511    +4     
  Branches    11164    11165    +1     
=======================================
+ Hits        29767    29771    +4     
  Misses        693      693           
  Partials       47       47           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[avinashbot]

I guess there's a backwards compatibility possibility when moving from ElementWrapper to ComponentWrapper, but realistically, I don't see how anyone could be using those, so it should be fine.