Page MenuHomePhabricator

CU 2.0: Implement an option to allow users to copy the wikitext of the results table to their clipboard
Closed, ResolvedPublic2 Estimated Story PointsJun 2 2020

Description

Goal

As part of their workflow, Checkusers often need to copy the results of the investigation to the private checkuser wiki. Traditionally they do this by manually copying over usernames, IPs, useragents etc. We can make this simpler by giving them the wikitext for the table we show in the Compare tab.

Mock

Acceptance criteria
  • There is a banner underneath the Compare tab table with a Copy button. (see mock)
  • Clicking the Copy button copies the wikitext for the table above.
  • The wikitext is for the table exactly as being shown. If data is filtered out, that is fine.
  • If the results span multiple pages, the Copy only copies the data on the page the user is on currently.

Event Timeline

Niharika triaged this task as Medium priority.Apr 29 2020, 4:10 AM
Niharika created this task.
Restricted Application added a subscriber: Aklapper. Β· View Herald TranscriptApr 29 2020, 4:10 AM
ARamirez_WMF renamed this task from CU 2.0: Implement an option to allow users to copy the wikitext of the results table to their clipboard to CU 2.0: Implement an option to allow users to copy the wikitext of the results table to their clipboard .Apr 29 2020, 4:37 PM
ARamirez_WMF set the point value for this task to 2.

I have some bad news for you. I wrote it that part but it was the part that took the most to write. Other parts of the gadget were a piece of cake compared to just making users copy the text. Mostly because you have to show the text to be copied to the user (w.wiki or gerrit.wikimedia.org simply do it) but in here we want to hide the wikitext. The only thing I found after a couple of hours of checking internet is that you make an object in -999999px somewhere and then select it and then you can copy it to clipboard.

@Ladsgroup When we were talking about this earlier, @dbarratt made the point that we could generate the wikitext in the PHP code of the extension. We are already pulling the data that's in the table through the PHP code so it shouldn't be that much more effort to make it available.

@Ladsgroup When we were talking about this earlier, @dbarratt made the point that we could generate the wikitext in the PHP code of the extension. We are already pulling the data that's in the table through the PHP code so it shouldn't be that much more effort to make it available.

Actually my point is that it's quite hard to make it available to be copied. You can generate the text using php or pull it from an API or natively build it in javascript but in all cases as long as user doesn't see it (hidden elements for example) it doesn't select and copy it, I think it's done for security reasons. Here's an example: https://hackernoon.com/copying-text-to-clipboard-with-javascript-df4d4988697f

Ahhh. I misunderstood. Thanks for clarifying.

@Ladsgroup When we were talking about this earlier, @dbarratt made the point that we could generate the wikitext in the PHP code of the extension. We are already pulling the data that's in the table through the PHP code so it shouldn't be that much more effort to make it available.

Actually my point is that it's quite hard to make it available to be copied. You can generate the text using php or pull it from an API or natively build it in javascript but in all cases as long as user doesn't see it (hidden elements for example) it doesn't select and copy it, I think it's done for security reasons. Here's an example: https://hackernoon.com/copying-text-to-clipboard-with-javascript-df4d4988697f

Makes me think we should pursue @Mooeypoo's idea of having a textbox that shows the text and then they can copy it over. @Ladsgroup If the text is visible in a textbox, will it simple to have a copy button that copies that text into their clipboard? Or is it easier to have the user manually select the text and copy it?

@Prtksxna Flagging this discussion for you.

Makes me think we should pursue @Mooeypoo's idea of having a textbox that shows the text and then they can copy it over. @Ladsgroup If the text is visible in a textbox, will it simple to have a copy button that copies that text into their clipboard? Or is it easier to have the user manually select the text and copy it?

@Prtksxna Flagging this discussion for you.

I don't know if my hack is acceptable for you but it's widely used in the web. You make a <textarea> object in CSS right: -999999px; position:absolute that basically is hidden but the browser still let you copy it (you can create the object once the user clicks on the button) and the only downside of it is when the user clicks, there will be long scroll in the page that will be gone if you destroy the object after it's copied to the clipboard (basically stays there for a very short time).

If you find a better way, let me know and I apply it in my gadget.

Huji added a subscriber: Huji.Apr 30 2020, 7:37 PM

Without knowing much about how browsers disable copying from hidden objects: what if the object is not hidden, but is not in the way either? A textbox with width and height of 1px, white border, white text, and overflow set to hide?

I don't know if my hack is acceptable for you but it's widely used in the web. You make a <textarea> object in CSS right: -999999px; position:absolute that basically is hidden but the browser still let you copy it (you can create the object once the user clicks on the button) and the only downside of it is when the user clicks, there will be long scroll in the page that will be gone if you destroy the object after it's copied to the clipboard (basically stays there for a very short time).

I think it's fine if we present the wikitext in a modal like we do on InteractionTimeline. Would that be acceptable @Prtksxna?

For reference, this is what InteractionTimeline does:

Button to share results

Clicking the button opens this popup:

The text is pre-selected. Clicking the "Copy" button adds it to the clipboard.

@Niharika Thanks! I imagine we'd use an OOUI modal, but yeah, something like that! :)

I think it's fine if we present the wikitext in a modal like we do on InteractionTimeline. Would that be acceptable @Prtksxna?

Yeah, just showing the Wikitext being copied is a good idea (especially in the cases where the browsers' copy button wont work). I think we could avoid the modal and expand the section to show the textarea right there:


If this could work, and if it makes sense, I could think further about the interaction.

I think it's fine if we present the wikitext in a modal like we do on InteractionTimeline. Would that be acceptable @Prtksxna?

Yeah, just showing the Wikitext being copied is a good idea (especially in the cases where the browsers' copy button wont work). I think we could avoid the modal and expand the section to show the textarea right there:


If this could work, and if it makes sense, I could think further about the interaction.

I like the idea of doing this. I think it will have to be a 2-step process to copy the wikitext. Based on Amir's comments above it seems like copying something that is not visible is hard. So step 1 would be to generate and show the wikitext and step 2 would be to allow user to copy it. Step 2 can be done with a Copy button but it won't be available until step 1 is done. Does that make sense?

I like the idea of doing this. I think it will have to be a 2-step process to copy the wikitext. Based on Amir's comments above it seems like copying something that is not visible is hard. So step 1 would be to generate and show the wikitext and step 2 would be to allow user to copy it. Step 2 can be done with a Copy button but it won't be available until step 1 is done. Does that make sense?

Yep, I was thinking this too 😊

…and after clicking on the button…

Would it be possible to have the text already selected? This would let people quickly hit Ctrl+C.

Would it be possible to have the text already selected? This would let people quickly hit Ctrl+C.

Yes. We can focus the input and highlight the text.

ARamirez_WMF set Due Date to May 12 2020, 4:00 AM.May 5 2020, 3:52 PM
ARamirez_WMF changed the subtype of this task from "Task" to "Deadline".
Niharika changed Due Date from May 12 2020, 4:00 AM to May 19 2020, 7:00 PM.May 7 2020, 3:35 PM

I was thinking that we could add a format "flag" to the existing API endpoint for the data. Then, we can request HTML, JSON, or Wikitext. Or, maybe all three at the same time. Is there a place in the code where we could do something like that?

I was thinking that we could add a format "flag" to the existing API endpoint for the data. Then, we can request HTML, JSON, or Wikitext. Or, maybe all three at the same time. Is there a place in the code where we could do something like that?

The Parse API can return either HTML prop=text or Wikitext prop=wikitext I imagine we could do something similar. :) If we generate the Wikitext (wherever) we can send arbitrary wikitext to be converted into HTML.

We can get the wikitext easily using Parsoid:

url = mw.config.get( 'wgVisualEditorConfig' ).fullRestbaseUrl + 'v1/transform/html/to/wikitext/';
data = $('.ext-checkuser-investigate-table-compare')[ 0 ].outerHTML;
// Then remove OOUI buttons, extra classes, etc...
$.ajax( url, { data: { html: data }, type: 'POST' } );

Availability of feature would then be dependent on the existence of mw.config.get( 'wgVisualEditorConfig' ) and mw.config.get( 'wgVisualEditorConfig' ).fullRestbaseUrl, but this is true for all public production wikis.

I'd be wary of generating the wikitext ourselves, given that a service already exists for converting HTML to wikitext. It's complicated, could introduce bugs, and could require more maintenance if we make changes to the Compare results.

dmaza removed dmaza as the assignee of this task.May 18 2020, 3:05 PM
dmaza added a subscriber: dmaza.

I'd be wary of generating the wikitext ourselves, given that a service already exists for converting HTML to wikitext. It's complicated, could introduce bugs, and could require more maintenance if we make changes to the Compare results.

Are you saying we should generate the wikitext from the HTML we output? What if the wiki doesn't have visualeditor (or parsoid) enabled?

I was thinking that it probably wont be a 1:1 output anyways (i.e. you don't need the ... menu, nor the filter icon, etc.), so it's fine to generate the wikitext ourselves, but I don't think we should provide HTML since as you mention there are existing APIs to convert it.

@dbarratt Every wiki with visual editor has Parsoid, and that's all public WMF wikis:

Availability of feature would then be dependent on the existence of mw.config.get( 'wgVisualEditorConfig' ) and mw.config.get( 'wgVisualEditorConfig' ).fullRestbaseUrl, but this is true for all public production wikis.

I agree we don't need the OOUI buttons, hence:

// Then remove OOUI buttons, extra classes, etc...

This amount of processing is simpler than generating wikitext from scratch. It also ensures that the wikitext will never be invalid (our code could have bugs with unbalanced wikitext, improper escaping, etc, and would need to be updated whenever the results table changes).

@dbarratt Every wiki with visual editor has Parsoid, and that's all public WMF wikis:

Are we dropping support for non-WMF wikis?

This amount of processing is simpler than generating wikitext from scratch. It also ensures that the wikitext will never be invalid (our code could have bugs with unbalanced wikitext, improper escaping, etc, and would need to be updated whenever the results table changes).

It still requires updating either way (we add an additional class or button or whatever). I'm not sure this is better and seems to extend outside of the use case of Parsoid...

@dbarratt Every wiki with visual editor has Parsoid, and that's all public WMF wikis:

Are we dropping support for non-WMF wikis?

VE also works only with Parsoid and still lots of non-WMF wikis have them (running Parsoid is not that hard). So requiring Parsoid doesn't mean "dropping support for non-WMF wikis".

VE also works only with Parsoid and still lots of non-WMF wikis have them (running Parsoid is not that hard). So requiring Parsoid doesn't mean "dropping support for non-WMF wikis".

I understand. I am surprised that requiring a dependency on a service is simpler than generating a table of wikitext.

Are we dropping support for non-WMF wikis?

Also, note that wikis without Parsoid would have everything else except this copy-paste feature - and the reason we're making the copy-paste feature is because it is useful for the WMF workflow.

Are we dropping support for non-WMF wikis?

Also, note that wikis without Parsoid would have everything else except this copy-paste feature - and the reason we're making the copy-paste feature is because it is useful for the WMF workflow.

That's true.

ARamirez_WMF changed Due Date from May 19 2020, 7:00 PM to Jun 2 2020, 7:00 PM.May 21 2020, 3:10 AM
ARamirez_WMF removed dmaza as the assignee of this task.May 21 2020, 3:41 PM

Change 598524 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Add feature for copying Special:Investigate results table

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

  • The wikitext is for the table exactly as being shown. If data is filtered out, that is fine.

@Niharika @Prtksxna Some of the appearance is due to the CSS that we specifically load on Special:Investigate (e.g. grey background colour for the target cells, yellow highlighting, etc). The users could copy over the CSS to the destination wiki, but they would need to keep it up-to-date.

@Niharika @Prtksxna Some of the appearance is due to the CSS that we specifically load on Special:Investigate (e.g. grey background colour for the target cells, yellow highlighting, etc). The users could copy over the CSS to the destination wiki, but they would need to keep it up-to-date.

From my understanding the tables on CU Wiki are kept as archives and for Ctrl-F searches, so it should be fine if the table looks and behaves differently as long as all the data is there.

I wasn't expecting the highlight to continue to work, but its cool to think that there might be ways in which it might. Thanks for pointing this out @Tchanders!

  • The wikitext is for the table exactly as being shown. If data is filtered out, that is fine.

@Niharika @Prtksxna Some of the appearance is due to the CSS that we specifically load on Special:Investigate (e.g. grey background colour for the target cells, yellow highlighting, etc). The users could copy over the CSS to the destination wiki, but they would need to keep it up-to-date.

Oh, I only meant that in terms of the data. We can drop the colors and hovers etc.

Change 598524 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Add feature for copying Special:Investigate results table

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

@Tchanders If the user being investigated does not have a User page, the wikitext username row looks like:

...
|[[User:$username (page does not exist)|<bdi>$username</bdi>]]
...

Which is not the correct link (obviously).

I think because the "title" attribute of the <a> element in the HTML is "$username (page does not exist)".

Change 606207 had a related patch set uploaded (by Tchanders; owner: Tchanders):
[mediawiki/extensions/CheckUser@master] Use URL querystring title for user page link in Special:Investigate

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

@Niharika Quick question about the wikitext generated for the user links. They are currently internal links to the user page on the same wiki on which the investigation was done. Do we expect the wikitext to be pasted into a different wiki, in which case, should they actually be external links?

@Niharika Quick question about the wikitext generated for the user links. They are currently internal links to the user page on the same wiki on which the investigation was done. Do we expect the wikitext to be pasted into a different wiki, in which case, should they actually be external links?

We discussed this in stand-up and seems like we do need an external link.

Change 606207 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] Use external user links in Special:Investigate wikitext copy tool

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

  • There is a banner underneath the Compare tab table with a Copy button. (see mock)

Looks like:

  • Clicking the Copy button copies the wikitext for the table above.

Yep.

  • The wikitext is for the table exactly as being shown. If data is filtered out, that is fine.

It also reflects the current state of sorting.

@Niharika Currently you can only generate wikitext once. If you want to regenerate the wikitext (for example, after changing the sorting) you have to refresh the page first. Might we want a regenerate ability?

  • If the results span multiple pages, the Copy only copies the data on the page the user is on currently.

Yep.

All the data looks correct, and is formatted very close to how it looks in Special:Investigate.

I briefly tested RTL behaviour. If the wiki into which you are copying the wikitext is RTL, then the wikitext table reflects how the table looks in Special:Investigate.

Username links are now fine.

Niharika closed this task as Resolved.Jul 31 2020, 10:23 PM