This isn't necessarily "won't ever fix", but the cost to secure SVG sufficiently is enormous and I can't imagine it making sense to pursue until we are a huge organization with as many as 4 or 5 full time engineers.

Looking through the security situation in more detail in response to a recent report via HackerOne, I think it's unlikely that we'll pursue support for this in the upstream. Browsers will execute Javascript and other dangerous actions (external includes, entity expansion) in SVGs, and there is no way to avoid this in a categorical way or otherise delegate security to the browser.

I think I can fix that. The current assumption is that the wrap is the result of multiple words:

Feel free to say no... but if you start an @ at the edge of the remarkup box, the text will move to the newline but the box won't.

I'm not planning to touch all the cases like ` #x, {nav #x, ``` #x, %%% #x, etc. We don't have a client-side Remarkup parser and I'm not planning to build one for this. See T3725#39466 for some earlier discussion.

This currently triggers autocomplete, but probably shouldn't: ` #f.

The only issue that I've noticed so far is that @{article: triggers the autocomplete, whereas it probably should not.

This would be ambiguous with other directives (lines, name, counterexample, etc).

@chad Thank you for quick clarification.

it's on master today and stable likely on Saturday depending on what branch you track.

@spicyj Good idea, thank you for the advice :-). I just wasn't sure this feature is in production...

@ablekh Have you tried Googling for "how to update phabricator"?

How do I get this feature? System update? If Yes, please point me to documentation, describing the update process. Thank you!

The most recent ruleset seems to be working pretty well for me. It hasn't been spazzing out and popping up all over the place, but has been there the couple of times I actually wanted it.

So the preview didn't show the text on multiple lines. :/

If I switch the setting to ["http","https","mailto","hyper","itms-services"], then the exception is gone. So I guess the format is a JSON array, not object. But like I said above, hyperlinks don't work at all.

Ah and when I attempt to save the doc, I get this error:

Unhandled Exception ("InvalidArgumentException")

Still doesn't seem to work: all links are broken in Phriction:

{ "http": true, "https": true, "mailto": true, "tel": true }

What's the format for setting? I tried ["http","https","mailto","hyper"] but it didn't work and actually breaks all links.

haha no idea, this arose from a product discussion about how project tags will render when there are 16 levels.

wait how do I get @epriestley points

are you kidding me, I spent all my @epriestley points on this as is.

Is there any intention to add support for auto-complete when typing like "T1234" or "D1234"? That would help immensely with instances that have a large number of tasks or diffs. I know there's been a few times on this instance where I've wanted to refer to diffs in task comments, but I can't remember the number perfectly so I have to open a Maniphest search to try and guess what number it was. Having it in the typeahead with the task / revision title would mean I don't need to spend time doing that.

From D15029:

ǝɯ ɹoɟ sʞɹoʍ ʎǝlʇsǝᴉɹdǝ@

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

In T10163#154399, @joshuaspence wrote:

Is it expected that this doesn't work on mobile?

Is it expected that this doesn't work on mobile?

In the case of 1 match, we now hide if there's one match and it's exactly what you typed.

I think that's what I intended to describe - hadn't considered if there was a single match but wasn't exactly what was typed. Thanks.

In T10163#154334, @cspeckmim wrote:

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Okay, all that stuff is live now too.

Yeah I'm finding implementation mixed at various sites.

I didn't do that because I don't think a space is universal -- I've seen ":" and ",", particularly.

I sort of expect it to also place a space for me after selecting the correct object.

That word stuff still has some weird/buggy results, I'll see if I can improve the behavior.

Alright, all that stuff is hopefully fixed/improved now:

That would change your case of @epriestley xvnoinoandsonaf having autosuggest stick around though.

I like that idea. Should it also hide if there are 0-1 matches? When mentioning users with short usernames or project names it's often faster to just type, @chad, @cspeck, #enad, etc.

Maybe we can do this:

That'll break @evan danger priestley and #differential mobile unbeta. I don't really see a clean way to resolve that based on spaces-typed, since both human and project names may contain an arbitrary number of internal words. We could put some artificial cutoff (three words? maybe four or five for projects?) but I don't immediately see a way to write a rule that always does what you users want.

@epriestley - Sorry, was just noting the different cases while testing -- most of the 'prefix' ones I gather made sense for the exact reasons you described. The only change I would prefer is if space also dismissed the typeahead - if completely ignoring typeahead it feels like it's in the way.

Another errata is when the typeahead appears off the page and you have to scroll. In Conpherence it, uh, scrolls the main header off the page.

Let's try the less-annoying way and see if it actually causes problems, it's definitely the behavior I would prefer personally.

But maybe it will feel weird, since I don't think most inline typeaheads work like that. On github as soon as I hit @, it pops a typeahead with you at the top (presumably, you're the commit author?)

From a design POV I see typeaheads as "Search", not "Browse". They should have some idea when they did @ or # what they were looking to link to.

Do you think that's preferable? I think it's probably much better for experienced users, but I'm a little worried some users will type a #, sit there, then tell us it's broken if we do that.

In T10163#154322, @epriestley wrote:

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

We could also decline to pop the typeahead until the user types the first (valid) character. Currently we pop it on @ or # immediately to show the user that it's available and aid discovery, but it might be better to wait until they type one valid character before we pop it, so there wouldn't be a flash on cases of ##, etc.

Typeahead starts when preceded by ., -, (, |, #, @

Some nuances I've tested:

1. Typeahead starts when preceded by ., -, (, |, #, @
2. Typeahead does not start when preceded by most other characters including ', ", ?, ,, /, {, }, [, ], ), :, >, < +, _, ;, !

Not sure if rP2d495e97014d made it on this install, but typing two # in a row still tries to autocomplete. Should it be dismissed if prior text is # as well (for headings/sections)?

Seeing as how you don't need to select a result for the mention to work, the inability to get the typeahead results back after dismissing them isn't that big of a deal either way, imo.

(1) is currently intentional -- I'm being pretty aggressive about throwing the prompt away, and dismiss it if you use "up" or "down" to get off the ends of the list, under the assumption those actions mean "throw this away, I hate it". I'm definitely open to changing those to just eat the inputs.

Ok, here's what just happened on my initial test run:

One thing I've done differently than, e.g., Facebook is that I've made summoning the completer explicit (when you type "@" or "#"), not implicit (when you position your cursor somewhere in something that looks like a username in the text).

(This seems to work really well for me, btw)

I heard @scp is also good at breaking things.

I can't break it with 30 seconds of attempt. Wonder what @joshuaspence will find.

That appears to be working better, now.

I think my analysis of the blur thing wasn't quite right, I'm still getting intermittent success with clicking results. I'll dig into that a bit more.

derp

In T10163#154221, @chad wrote:

If I type @demo and then tab it changes to @abuna

If I type @demo and then tab it changes to @abuna