Add browser search and richer URL matching
This commit is contained in:
@@ -93,6 +93,28 @@ Chromium / Chrome:
|
||||
- Username and password fields get an inline KeePassGO affordance that opens a candidate chooser anchored to the focused field and keeps fills scoped to that field's form when possible.
|
||||
- If a fill request needs user approval, the extension keeps the pending state visible in both the page affordance and the popup until KeePassGO resolves it, using the token-scoped pending-approval count from the local gRPC API.
|
||||
|
||||
## Search And Matching
|
||||
|
||||
User story:
|
||||
|
||||
- When a page has no obvious match, the popup still lets the user search the
|
||||
vault without leaving the browser.
|
||||
- Search results must stay scoped to what the current API token can actually
|
||||
access.
|
||||
- Browser matching must treat common KeePass data conventions as real browser
|
||||
targets, not just the primary `URL` field.
|
||||
|
||||
Expected behavior:
|
||||
|
||||
- The popup exposes a `Search Vault` field that queries KeePassGO directly.
|
||||
- Search results use the same fill path as page matches.
|
||||
- Search never leaks entries outside the token's authorized group scope.
|
||||
- A browser match can come from:
|
||||
- the primary `URL` field
|
||||
- scheme-less host values such as `gitlab.com`
|
||||
- custom URL fields such as `URL1`, `URL2`, and similar KeePass-style URL
|
||||
slots
|
||||
|
||||
For extension-side regression checks, run:
|
||||
|
||||
```bash
|
||||
|
||||
Reference in New Issue
Block a user