@Ladsgroup has built a gadget that does something similar in https://github.com/Ladsgroup/CheckUserHelper/blob/master/Gadget.js

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.

In T251361#6095779, @aezell wrote:

@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.

In T251361#6097802, @Ladsgroup wrote:

In T251361#6095779, @aezell wrote:

@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.

In T251361#6098124, @Niharika wrote:

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.

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?

In T251361#6098411, @Ladsgroup wrote:

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! :)

In T251361#6098519, @dbarratt wrote:

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:

In T251361#6101809, @Prtksxna wrote:

In T251361#6098519, @dbarratt wrote:

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?

In T251361#6102374, @Niharika wrote:

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 😊

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

In T251361#6103228, @Prtksxna wrote:

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.

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?

In T251361#6126949, @aezell wrote:

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.

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).

In T251361#6146203, @Tchanders wrote:

@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...

In T251361#6148875, @dbarratt wrote:

In T251361#6146203, @Tchanders wrote:

@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".

In T251361#6148877, @Ladsgroup wrote:

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.

In T251361#6148891, @Tchanders wrote:

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.

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.

In T251361#6163726, @Tchanders wrote:

@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!

In T251361#6163726, @Tchanders wrote:

• 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?

In T251361#6244250, @Tchanders wrote:

@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.

Looks good. Noting some minor visual changes here - T257018.