Summary: Noticed a couple of typos in the docs, and then things got out of hand.
Test Plan:
- Stared at the words until my eyes watered and the letters began to swim on the screen.
- Consulted a dictionary.
Reviewers: #blessed_reviewers, epriestley
Reviewed By: #blessed_reviewers, epriestley
Subscribers: epriestley, yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
Differential Revision: https://secure.phabricator.com/D18693
Summary:
Ref T10252. The previous fix rPa8a9fddb0738 only works for macOS.
Under Windows the @ symbol is composed of AltGr+q. For Chrome and Edge the "AltGr" keypressEvent is like pressing the Control key and the Alt key at the same time.
This fix changes the condition in such a way, that this case (pressing Control and Alt at the same time) is not blocked.
Test Plan:
Testing for the issue:
- Launch Windows 10, Select German Keyboard, Use latest Chrome (60)
- Observe typing `@` does not trigger typeahead
- Apply patch, retest, see typeahead.
Regression tested:
- Windows 10, Chrome, Firefox, Edge
- Mac OS, Chrome, Firefox, Safari
- Keyboard layouts, English, French, German, Spanish
All tests passed
Reviewers: benwick, epriestley
Reviewed By: epriestley
Subscribers: epriestley
Maniphest Tasks: T10252
Differential Revision: https://secure.phabricator.com/D18269
Summary:
Send-on-enter and autocomplete both listen for "return" keypresses, and could race. Have autocomplete let other handlers take a shot at the action before it does.
Also, fix a case where ":)" and the suffix list (which lets you type `someone is 100% to blame here (@epriestley)` and get the results you want) interacted badly, so ":)" cancels the autocompleter like ":3" does.
Test Plan:
- Typed "@xxx" and mashed return real fast over and over again while reloading the page. Before: sometimes handlers raced and text submitted. After: always handled by autocomplete behavior.
- Typed ":", ")", "<return>", sent an emoticon (previously: no).
Reviewers: chad, amckinley
Reviewed By: chad
Subscribers: xxx
Differential Revision: https://secure.phabricator.com/D17794
Summary:
Fixes T12538. Instead of hiding "closed" results unless only closed results match, show closed results but sort them to the bottom.
This fixes the actual issue in T12538, and I think this is probably the correct/best behavior for the global search.
It also makes all other typeaheads use this behavior. They currently have a "bug" where enabled user `abcd` makes it impossible to select disabled user `abc`. This manifests in some real cases, where enabled function `members(abc)` makes it impossible to disabled user `abc` in some function tokenizers.
If ths feels worse, we could go back to filtering in the simpler cases and introduce a rule like "show closed results if only closed results would be shown OR if query is an exact match for the disabled result", but that gets dicier because "exact match" is a fuzzy concept.
(There are a lot of other minor bad behaviors that this doesn't try to fix.)
Test Plan:
Enabled project "instabug" no longer prevents bot user "instabug" from being shown:
{F4903843}
Disabled user "mmaven" is sorted below enabled user "mmclewis", in defiance of the otherwise alphabetical order. There's no visual cue that this user is disabled because of T6906.
{F4903845}
Same as above, but this source renders "disabled" in a more obvious way:
{F4903848}
Function selecting members of active project `members(instabug)` no longer prevents selection of bot user `instabug`:
{F4903849}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12538
Differential Revision: https://secure.phabricator.com/D17695
Summary:
Fixes T12479. If you end a line with a character like ":" in a context which can trigger autocomplete (e.g., `.:`), then try to make a newline, we swallow the keystroke.
Instead, allow the keystroke through if the user hasn't typed anything else yet.
Test Plan:
- Autocompleted emoji and users normally.
- In an empty textarea, typed `.:<return>`, got a newline instead of a swallowed keystroke.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12479
Differential Revision: https://secure.phabricator.com/D17583
Summary:
Fixes T12460. Also ":)", ":(", ":/", and oldschool ":-)" variants.
Not included are variants with actual letters (`:D`, `:O`, `:P`) and obscure variants (`:^)`, `:*)`).
Test Plan: Typed `:3` (no emoji summoned). Typed `:dog3` (emoji summoned). Typed `@3` (user autocomplete summoned).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T12460
Differential Revision: https://secure.phabricator.com/D17577
Summary:
This adds a more complete emoji datasource, with a typeahead and autocomplete. It works by pulling in a raw datasource from EmojiOne (I chose Unicode 8, but they have a Unicode 9 datasource as well) and transforming it for speed/need. If we build more robustness or an actual picker into the Remarkup bar, having the additional keywords, etc, might be important. When Unicode 9 support is more prevalent, we should only need to update the single file.
Tossing up as a proof of concept on engineering direction. Also I can't quite get the autocomplete to complete.
Test Plan: Test UIExamples, Autocomplete, and TypeaheadSource
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Maniphest Tasks: T12139
Differential Revision: https://secure.phabricator.com/D17244
Summary:
Ref T10252. On the German keyboard layout, you must type "Alt" + "L" to generate an "@" character.
We currently ignore this event, assuming it's a keyboard command. However, I think we can safely continue so that autocomplete works on German layouts.
Test Plan:
- Switched keyboard layout to German.
- Typed Alt + L to generate an "@".
- Typed some username text.
- Got autocompleter.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10252
Differential Revision: https://secure.phabricator.com/D16259
Summary: Ref T10163. These are almost certainly not username/project characters, and are fairly likely to be `@{...}` Diviner references.
Test Plan: Typed `@{...`, no more autocomplete.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15110
Summary:
Ref T10163. If you right-click the suggestion menu, just eat it. I don't think we can really choose a different behavior reasonably, or that users have any reason to do this.
I'm leaving "clicking the header dismisses it", I think that behavior is fine and reasonable.
Test Plan: Control-clicked a suggestion menu, didn't trigger a suggestion.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15042
Summary: Ref T10163. When a user autocompletes, add a space for them, unless they already added a comma, colon, or space themsevles.
Test Plan: Autocompleted `@dog`, got `@dog `. Autocompleted `@epriestley,` got `@epriestley,`.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15041
Summary:
Ref T10163. Currently, we don't activate on indented lines, but were too aggressive about this, and would not activate on lines like ` - Hey, @user...`, where we should.
Instead, don't activate on indented lines if there's only an indent (i.e., `#` probably means enumerated list).
Also, if results don't have autocompletes (rare but possible with projects missing slugs), improve behavior.
Test Plan:
- Typed ` #a`, got no autocomplete.
- Missing slug thing is a pain to test locallly, `#1 z z z z` reproduces in production. I'll just verify it there.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15040
Summary:
Ref T10163. When we think the user has finished typing a word (because they typed a space, period, or other similar characters) and nothing else they might type could possibly change the outcome (usually because the words they have typed already match nothing), just deactivate the autocomplete.
As a special case, if the word they have typed already select exactly one result, //and// they have already typed exactly that result, assume they just typed it from memory and deactivate.
Test Plan:
- Typed `@dog qwer zxcv` and saw autocomplete deactivate on the space before `z` (on my local install, `@dog` is ambiguous but `@dog qwer` matches nothing).
- Typed `@epriestley ` and saw autocomplete deactivate on space.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15039
Summary: Ref T10163. In cases like Conpherence, the autocompleter can currently render off the bottom of the screen. Put it above if it would be offscreen.
Test Plan: {F1062286}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15038
Summary: Ref T10163. Activate on `@d`, not just `@`. Note that if you type `@d` and then press delete once so you're left with `@`, we stay active (and show the "type a username" hint).
Test Plan:
- Typed `@`, no completer.
- Typed `d`, got completer.
- Typed delete, still had completer, now showing hint prompt.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15037
Summary:
Ref T10163. Some characters are almost certainly punctuation or markup rather than autocomplete requests. Immediately cancel any active autocomplete when the user types one of these.
Note that some of these are also suffix characters. If you type `@dog,`, you have until the next character to decide you actually mean to autocomplete. Once you type something else we deactivate.
If you type `#dog#` or `##`, we deactivate immediately.
Test Plan: Typed `@dog#`, etc.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15036
Summary: Ref T10163. This allows activation in blockquotes or after `NOTE:`, for consistency.
Test Plan: Typed `>@dog`, etc., got autocomplete.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15035
Summary:
Ref T10163.
- If a user types an autocomplete character ("@" or "#") and then a space, deactivate immediately (probably an ordered list).
- If a user types an autocomplete character indented on a line with no other prior text, don't activate (probably an ordered list or code block).
Test Plan:
Typed:
- `# `, saw immediate deactivation.
- ` #`, saw no activation in the first place.
- `#x`, saw activation.
- `asdf #x`, saw activation.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15033
Summary: Ref T10163. I would still sometimes not get a replacement after clicking with the delayed blur. This seems to fix the issue more consistently: instead of listening for a click event (which fires after the blur), listen for a mousedown event (which fires before the blur).
Test Plan: Observed consistent selection via mouse locally.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15032
Summary:
Ref T10163.
- If you click a result, we get a blur before your click hits, and deactivate before the click can work. Instead, wait before responding to blur.
- Use the standard sort handler which puts unixnames over human names. Also use the standard filter which deals with disabled users not matching unless they're the only match.
Test Plan:
- Clicked a result, got a replacement.
- Named myself "dog dog", typed "@dog", user "@dog" was now first match despite me being "@admin".
- Used normal typeaheads to make sure I didn't break sort handler.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10163
Differential Revision: https://secure.phabricator.com/D15031
Summary: Ref T3725. This probably has 900,000 bugs. This will need updates for subprojects/milestones.
Test Plan:
- Tested very gently in Safari, Firefox and Chrome.
- Reasonable inputs appear to work.
- Clicking, escape, tab, return, arrow keys work OK?
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T3725
Differential Revision: https://secure.phabricator.com/D15029
