Page MenuHomePhabricator

Preserve @ sign if user closes mention inspector empty
Closed, ResolvedPublic

Description

This is designed to allow typing an @ sign despite the sequence shortcut (with the current patch, you have to copy/paste from elsewhere).

When you type @, it will open. Then, if you escape without typing a username, an @ sign will be added to the VisualEditor document.

See also: T94109: Click outside to close doesn't always work as intended for mention inspector

Event Timeline

Mattflaschen-WMF raised the priority of this task from to Needs Triage.
Mattflaschen-WMF updated the task description. (Show Details)
Mattflaschen-WMF renamed this task from Preserve @ sign if use closes mention inspector to Preserve @ sign if user closes mention inspector.Mar 27 2015, 6:59 PM
Mattflaschen-WMF renamed this task from Preserve @ sign if user closes mention inspector to Preserve @ sign if user closes mention inspector empty.
Mattflaschen-WMF set Security to None.

Change 205100 had a related patch set uploaded (by Esanders):
Improve user experience when using '@' sequence trigger for mentions

https://gerrit.wikimedia.org/r/205100

EBernhardson subscribed.

Change 205100 merged by jenkins-bot:
Improve user experience when using '@' sequence trigger for mentions

https://gerrit.wikimedia.org/r/205100

Does not look that it is done in current betalabs env.

if you escape without typing a username, an @ sign will be added to the VisualEditor document.

Returning the bug back to In Development

Works in Chrome.

FF 36 does not look good.

  • Typing @ will open the mention inspector at the upper left corner dis

Screen_Shot_2015-04-27_at_9.27.35_AM.png (325×1 px, 40 KB)

  • and the mention inspector becomes very sticky - cannot get irid of it until the page is updated.

Works in Chrome.

FF 36 does not look good.

  • Typing @ will open the mention inspector at the upper left corner dis

Screen_Shot_2015-04-27_at_9.27.35_AM.png (325×1 px, 40 KB)

  • and the mention inspector becomes very sticky - cannot get irid of it until the page is updated.

I can't reproduce this locally.

Are there any errors in the browser console when this happens?

Looks like I can reproduce this in beta labs after all, I get Error: Offset could not be translated to a DOM element and offset: 7.

I've now gotten Chrome to give me this error too. Assigning to Ed as this is a bug in VE.

I believe this will be fixed by https://gerrit.wikimedia.org/r/206951

This is merged now, so the Firefox issue (which also occurred in Chrome if you typed @ directly after another mention) should be fixed.