[OCISDEV-843] Flaky search test - 2nd fix

[deyankiteworks]

Summary

• Uses resourcePage.filesList instead of resourcePage.searchList for asserting search results after pressing Enter
• After pressing Enter, the test navigates to the full search results page which renders via ResourceTable with [data-test-resource-path] selectors — NOT the dropdown (#files-global-search-options)
• Removes the unnecessary 2000ms waitForTimeout workaround from the first fix attempt

Related Issue

• Fixes #OCISDEV-843

Test plan

• Verify the "Search in personal spaces" test passes consistently in CI
• Confirm no regressions in other search tests

🤖 Generated with Claude Code

[update-docs]

Thanks for opening this pull request! The maintainers of this repository would appreciate it if you would create a changelog item based on your changes.

[anon-pradip]

My opinions:

@deyankiteworks @mzner

Why was it passing before then?

It wasn't. That's the whole reason OCISDEV-843 exists. The test was already flaky. The original playwright port (commit 9bd7e30cc) had the exact same code: presses enter + titleOnly + searchList. It was broken from day one — just got lucky sometimes. I also tried many times to fix it but no luck.

Why does filesList fix it?

After pressing Enter, two things happen:

1. onKeyUpEnter in SearchBar.vue:518 calls optionsDrop.hide() (hides the dropdown via Tippy.js), then router.push() navigates to the full results page (List.vue).
2. List.vue renders search results in a <resource-table> (visible on page).

The assertion then reads from the wrong DOM element:

• searchList = //div[@id="files-global-search-options"]//li[...]//span[@class="oc-resource-name"] — reads from the hidden Tippy dropdown (#files-global-search-options)
• filesList = [data-test-resource-path] — reads from the visible resource table on the full results page

After Enter, the actual search results live in the resource-table (where List.vue renders them). The title-only toggle works on this same table. But searchList reads from the hidden dropdown which has stale/empty content — the search() function in SearchBar.vue:483 starts with searchResults.value = [], and when the route changes, parseRouteQuery re-sets term.value which can trigger a re-search that clears dropdown results mid-flight.

So @deyankiteworks Were you testing this test locally with Tika enabled? Because Without Tika, fullTextSearchEnabled is false → List.vue:77 has v-if="fullTextSearchEnabled" → the title-only button never renders → userEnablesTitleOnlySearch times out → same crash regardless of selector. You might have seen it fail with filesList, and you again reverted to searchList, and saw it also fail — concluding that the selector wasn't the problem. But it might be that you were simply hitting a different root cause (missing Tika) that masked the fix.

[anon-pradip]

@deyankiteworks

On PR #13831, I ran the search test 10 times in CI with the filesList selector fix — all 10 passed (link: #13831).

• https://github.com/owncloud/web/actions/runs/26771131056
• https://github.com/owncloud/web/actions/runs/26771130733
• https://github.com/owncloud/web/actions/runs/26769974641
• https://github.com/owncloud/web/actions/runs/26769974557

The one-line change in search.spec.ts:285:

resourcePage.searchList → resourcePage.filesList

After presses enter, onKeyUpEnter in SearchBar.vue:518 calls optionsDrop.hide() and router.push() to the full results page (List.vue).

The results render in <resource-table> (uses data-test-resource-path), not in the #files-global-search-options dropdown anymore. So:

• searchList (reads from #files-global-search-options) reads stale/empty DOM.
• filesList (reads [data-test-resource-path]) reads the actual visible table.

Your rework in this PR avoids this by removing presses enter + titleOnly from the assertion, which also works, but drops test coverage for the "title-only filter on full results page after Enter" flow.

If you'd rather keep that coverage, you could take the filesList fix instead and revert the rework to search.difficult.names back to the original flow.

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[deyankiteworks]

@deyankiteworks

On PR #13831, I ran the search test 10 times in CI with the filesList selector fix — all 10 passed (link: #13831).

• https://github.com/owncloud/web/actions/runs/26771131056
• https://github.com/owncloud/web/actions/runs/26771130733
• https://github.com/owncloud/web/actions/runs/26769974641
• https://github.com/owncloud/web/actions/runs/26769974557

The one-line change in search.spec.ts:285:

resourcePage.searchList → resourcePage.filesList

After presses enter, onKeyUpEnter in SearchBar.vue:518 calls optionsDrop.hide() and router.push() to the full results page (List.vue).

The results render in <resource-table> (uses data-test-resource-path), not in the #files-global-search-options dropdown anymore. So:

• searchList (reads from #files-global-search-options) reads stale/empty DOM.
• filesList (reads [data-test-resource-path]) reads the actual visible table.

Your rework in this PR avoids this by removing presses enter + titleOnly from the assertion, which also works, but drops test coverage for the "title-only filter on full results page after Enter" flow.

If you'd rather keep that coverage, you could take the filesList fix instead and revert the rework to search.difficult.names back to the original flow.

@anon-pradip

Thanks for the comments and the proposed fix. I reverted back the filesList fix, tested locally few times the whole search.spec.ts and it passed successfully.
I also force pushed this change and waiting for the runners to run the CI jobs.

Let's wait the CI jobs to finish and to check if the flaky search test will pass successfuly.

[sonarqubecloud]

Quality Gate failed

Failed conditions
39.9% Condition Coverage on New Code (required ≥ 50%)

See analysis details on SonarQube Cloud