Page MenuHomePhabricator

Black cloud upon pasting a ref into the Basic citation dialog in Safari (9 and below only?)
Open, LowPublic8 Estimated Story Points

Description

https://en.wikipedia.org/w/index.php?diff=703456232&oldid=703194441

Steps to cause this problem:

  1. Open a page that contains refs.
  2. Select a ref (click on a "[1]") and copy it (Command-C).
  3. Click the Cite button and choose the "Basic" form.
  4. Paste the ref into the dialog.
  5. See the black cloud!
  6. Save the page.
  7. File this bug.

This happened in Safari 9 on Mac 10.10.5. I have not been able to reproduce this again.

Event Timeline

Whatamidoing-WMF raised the priority of this task from to Needs Triage.
Whatamidoing-WMF updated the task description. (Show Details)
Whatamidoing-WMF added a project: VisualEditor.
Whatamidoing-WMF added a subscriber: Whatamidoing-WMF.

A bit of tracking this down:

It's a Safari bug, not a general WebKit-family bug; it doesn't happen in Chrome. It also doesn't happen in the Safari Technology Preview, so presumably it's something that'll go away on its own if we ignore it. (I don't have the macOS beta installed, so I don't know where the Safari in it falls on this spectrum.)

We only insert ☁ if there's literally no text content in the paste destination, and it only persists after the paste if the cite was the entire contents of your paste.

If there is content already in the paste destination, pasting just-a-cite has the interesting effect of resetting the cursor position to the start of the document, instead of leaving it where it is.

Jdforrester-WMF renamed this task from Black cloud upon pasting a ref into the Basic citation dialog to Black cloud upon pasting a ref into the Basic citation dialog in Safari (9 and below only?).Sep 7 2016, 4:54 PM

Yeah, just tested in Safari 10.0 preview (in Mac OS 10.12 Beta 7); nothing gets inserted (instead of a black cloud), and the cursor gets moved to the start of the surface.

Presumably the preferred action would be to put the contents of the <ref> into the surface instead?

The current behavior if you're pasting more than just a solitary-ref seems to be to convert it into not-a-ref. i.e. literally pasting in foo<sup>[1]</sup>.

I can see a bunch of UI arguments here...

  • We could make it be [1] for consistency with the in-other-text case.
  • We could make it be the contents of the other ref, as a shortcut for duplicating the ref and editing it.
  • We could make it turn into a shortcut to reusing the existing ref and immediately editing it, though people might not expect it to do that.

I like option 2. Option 3 would not be possible if the target (rather than source) reference already has contents (without obliterating the contents), and Option 1's consistency is high but its do-what-the-user-actually-wants seems low. :-)

Right now this is consistent in Safari 10+ and Chrome, but old Safari has (had?) an issue. Perhaps we should down-scope this to just the make-Safari-9-consistent bit, and spin out the "what would be nice?" item to another task?

How much usage does Safari 9 have, relatively speaking? I'm doubting this is a high priority issue.

Well, trusting https://analytics.wikimedia.org/dashboards/browsers/, it seems Safari in its entirty has a 2.8% share on our sites this month, and only 29% of that is Safari 9 or below. So 0.812% of our overall browser usage is this.

Deskana lowered the priority of this task from High to Low.Oct 19 2017, 7:43 PM
Deskana moved this task from TR0: Interrupt to Freezer on the VisualEditor board.

Thanks. Sadly, I must deprioritise.