fix(e2e): match nav links and URLs as paths, not hashes - #584
Merged
Conversation
Follow-up to #582, which turned E2E red on development. Three selectors and one URL assertion still described hash routing: a[href$="#/"] the Dashboard nav entry a[href$="#/lock"] the Lock vault entry (twice) toHaveURL(/#\/lock$/) and /#\/(?!lock)/ after unlock Under history routing those match nothing, so the nav assertions failed on 'element(s) not found' rather than on anything about navigation. Matched as SUFFIXES rather than whole hrefs: Nextcloud serves the app as both /apps/keepiq/... and /index.php/apps/keepiq/..., and the link carries whichever base the page was loaded under, so pinning either would fail on the other for a reason that is not a defect. The existing comment already made that argument for the hash form; it now makes it for the path form. The post-unlock assertion is inverted rather than retargeted: it now asserts we LEFT /lock instead of naming the destination, which varies with the returnUrl the gate captured. Verified: no hash href selectors and no hash URL assertions remain in tests/; prettier --check on the full glob is clean.
Contributor
Quality Report — ConductionNL/keepiq @
|
| Check | PHP | Vue | Security | License | Tests |
|---|---|---|---|---|---|
| lint | ✅ | ||||
| phpcs | ✅ | ||||
| phpmd | ✅ | ||||
| psalm | ✅ | ||||
| phpstan | ✅ | ||||
| phpmetrics | ✅ | ||||
| eslint | ✅ | ||||
| stylelint | ✅ | ||||
| build | ✅ | ||||
| check-manifest | ✅ | ||||
| test-l10n | ✅ | ||||
| format | ✅ | ||||
| check-l10n-js | ✅ | ||||
| check-schema-l10n | ✅ | ||||
| composer | ✅ | ✅ 111/111 | |||
| npm | ✅ | ✅ 536/536 | |||
| app:check-code | ⏭️ | ||||
| info.xml | ✅ | ||||
| REUSE | ❌ | ||||
| PHPUnit | ✅ | ||||
| Newman | ✅ | ||||
| Playwright | ⏭️ deferred — runs on the promotion into beta/main, not on a pull request into development | ||||
| Hydra gates | ✅ |
Quality workflow — 2026-09-01 10:02 UTC
Download the full PDF report from the workflow artifacts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #582, which turned E2E red on development. Three selectors and one URL assertion still described hash routing:
a[href$="#/"]a[href$="#/lock"]toHaveURL(/#\/lock$/)and/#\/(?!lock)/Under history routing those match nothing, so the nav assertions failed on "element(s) not found" rather than on anything about navigation.
Matched as suffixes rather than whole hrefs: Nextcloud serves the app as both
/apps/keepiq/...and/index.php/apps/keepiq/..., and the link carries whichever base the page was loaded under, so pinning either would fail on the other for a reason that is not a defect. The existing comment already made that argument for the hash form; it now makes it for the path form.The post-unlock assertion is inverted rather than retargeted: it asserts we left
/lockinstead of naming the destination, which varies with thereturnUrlthe gate captured.Verified: no hash href selectors and no hash URL assertions remain in
tests/;prettier --checkon the full glob is clean.