Composer multiselect adds selectable recipients from first autocomplete GET action
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 1k
- Forks
- 348
- Avg merge
- 12h 28m
- Merged PRs (30d)
- 91
Description
Steps to reproduce
- You must have contacts in your Contacts app (the more, the better: 'Apple Contact', 'Banana Contact', 'Grape Contact')
- Click 'New Message'
- Start search in 'To' field. Type 'a'....
- Wait till autocomplete?term=a ended
- See - 3 recipients in Multiselect
- Quickly add 'pple'
- Wait till autocomplete?term=apple ended
- See 1 recipients in Multiselect
- Click on that one
- After multiselect clears value, other contacts from FIRST request added to Multiselect
Expected behavior
Selectable recipients will must changed, when request results ate changed (autocomplete?term=xxxxxx)
Actual behavior
Selectable recipients takes from first autocomplete request
Mail app version
No response
Mailserver or service
No response
Operating system
No response
PHP engine version
No response
Web server
No response
Database
No response
Additional info
Based on - https://github.com/nextcloud/mail/pull/7240#issuecomment-1246598547
In my case there are 500 recipients. In Composer Multiselects there are 1500 (3x500).
Browser sleeping some times if I sleeping and s l o w l y t y p i n g
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the Composer multiselect and trace how autocomplete?term requests update selectable recipients as the search text changes. Reproduce the slow-typing sequence with several contacts; done means selecting a result after a newer request does not add recipients from the first request, and the multiselect remains consistent with the latest results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- frontend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100