[Bug] ACL "Select a user or team" dropdown shows no results on open without typing (regression in 21.0.6)

Bug Description

In the Files sidebar, the "Advanced permissions for Team folder" section's
"Select a user or team" dropdown shows "No results" when opened without
typing anything. Previously (before 21.0.6), all members of the groups
assigned to the folder were shown automatically on open.

Steps to Reproduce

1. Create a Group Folder with Advanced Permissions (ACL) enabled
2. Assign one or more groups to the folder
3. Navigate to the folder in the Files app
4. Open the sharing sidebar (right-click → Share, or click the share icon)
5. Scroll to "Advanced permissions for Team folder"
6. Click the "Select a user or team" input to open the dropdown

Result: Dropdown opens immediately showing "No results"

Expected: All members of the folder's assigned groups should be listed
(as they were before 21.0.6)

Workaround

Type any character (e.g. a or 1) into the search field, then delete it.
This triggers the API call GET /apps/groupfolders/folders/{id}/search?format=json&search=
and the group members appear correctly.

Root Cause Analysis

Inspecting browser DevTools → Network tab confirms:

• On dropdown open (no typing): No API call is made at all
• After typing then clearing: GET search?format=json&search= is called
  (200 OK, returns correct group members)

The search function in SharingSidebarView.vue (line 131) is wrapped in a
debounce (pl(A, 300)) and is only triggered on user input events. There is
no initial fetch when the dropdown opens with an empty query. A previous
version must have triggered an initial load — this behavior appears to have
been lost in 21.0.6.

The server-side API (FolderController::aclMappingSearch) works correctly:
when called with search= (empty string), it returns all members of the
groups assigned to the folder via FolderManager::searchUsers().

Additional Bug: Japanese input causes double-encoding → empty results

When users type Japanese characters in the search field, the input is
double-encoded before being sent to the server:

• User types: 共有
• Expected URL: search?format=json&search=%E5%85%B1%E6%9C%89
• Actual URL: search?format=json&search=%25E5%2585%25B1%25E6%259C%2589

The server receives the literal string %E7%A6%8F%E5%85%83 (percent signs
included) as the search query, which matches no display names, returning an
empty result. Roman characters work correctly.

The likely cause is a double call to encodeURIComponent() on the search
string before it is passed to the URL template substitution.

Environment

Item	Value
Nextcloud version	33.0.2
groupfolders version	21.0.6
PHP	8.3.6
Browser	Chrome 147
OS	Ubuntu 24.04 LTS

Regression

This worked correctly before the 21.0.6 update (installed 2026-04-04).
The groupfolders app directory mtime confirms the update date:
Modify: 2026-04-04 21:34:45

Summary of Bugs

#	Description	Severity
1	Dropdown shows no results on open (no initial API call)	High — breaks basic ACL user selection
2	Japanese/non-ASCII input double-encoded → always empty	Medium — workaround: use Roman characters

Start in SharingSidebarView.vue around the search function and its debounced input handling, then trace the GET /apps/groupfolders/folders/{id}/search endpoint to FolderController::aclMappingSearch and FolderManager::searchUsers(). Verify the dropdown fetches members when opened with an empty query and that Japanese input is encoded once, then reproduce both cases in the Files sharing sidebar.