copy to clipboard button for mediawiki code boxes

phabricator-migrator · February 19, 2024, 5:53pm

Information

ID: 93
PHID: PHID-TASK-t7q7f2gbk2j27gxpj6hg
Author: JasonJAyalaP
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

A “Copy to clipboard” link above/below all code boxes. Either always visible or when you hover over it.

Investigate a mediawiki extension that doesn’t require flash.

Any idea how to implement it?

Comments

Patrick

2015-01-16 21:32:59 UTC

Linostar

2015-01-17 07:28:19 UTC

Actually, that is an issue that has caused frustration to many js developers over the years.

There are many reasons why it isn’t practical (or possible) to implement it with javascript:
1- Cross-browser compatibility. Each browser handles the clipboard in a different way, and some are more picky than others.
2- Privacy and Security. It is considered a security issue to allow the browser to write to the clipboard. If it can write there, it can also read, and the clipboard may occasionally contain sensitive information such as credit card numbers, passwords, etc copied by other applications or browser windows. Furthermore, in some browsers like Firefox, one needs to change a variable value in about:config in order to enable this functionality, and ugly message will appear asking the user for permission or warning him whenever javascript triggers a clipboard copy.

For those reasons, developers usually use third-party apps such as Flash to implement this feature. Not only it will look less ugly with Flash, but implementing it with javascript wouldn’t be more secure than implementing it with Flash.

The example linked to in the comment above, that uses jQuery, does not in fact copy the text to clipboard. All it does is to select the text for the user so he/she can press CTRL+C to copy it. Needless to say, it is a method that can be coded with js only without requiring jQuery. It is like half a solution, where you do the selection (which may spare the user the effort when the content to select is large) and leave the other half of the copying procedure to the user fingers. It’s an approach that is somewhat popular among those who want to rely only on javascript.

I tested myself many js snippets in the past, that claim to do the job completely, and found that most of them don’t work anymore (use deprecated functions) or work only for certain browsers and with certain constraints and limitations. I suggest that making a “select all text” button is sufficient, since anything beyond isn’t worth the effort.

Sorry for the short essay… err… the long post.

Patrick

2015-01-19 00:53:51 UTC

Okay. If that is most we can do, then we should go for it. I think I saw such a box before somewhere. Dunno where. But it’s useful, no?

Would you know how to implement it in the wiki? Could you try on some test page such as https://www.whonix.org/wiki/Translatetest please?

Usually we’re using the <pre> tag for stuff that is supposed to be copied.
<pre>
test text box here
</pre>
We can also use the <html> tag.

When it works, we should be able to make that a mediawiki template.

crackman

2015-01-19 01:23:01 UTC

Patrick

2015-01-19 01:55:56 UTC

crackman

2015-01-19 05:15:54 UTC

Linostar

2015-01-19 15:49:56 UTC

! In T93#1044, @crackman wrote:
Patrick,
Trying a bit now. Can you enable javascript in the wiki settings somewhere for the testing to work?
As it stands I cannot make any javascript work - it gets read as text rather than a script.

Make sure you can only enable in that one page, lest someone try to hijack the site.
If we cannot get Javascript to work, we’ll have to just leave it as “user selects, copies, pastes themselves”

Javascript is enabled by default in the wiki. You just forgot to enclose your tags within tags.

Since ClipboardEvent API works only on Firefox currently, the same goes for it as I explained in my previous comment. It isn’t practical to deploy a solution that won’t work for some of the users.

I’ll work on making a template for the “select code” button.

Patrick

2015-01-19 15:57:39 UTC

Linostar

2015-01-19 16:10:38 UTC

Patrick

2015-01-19 16:13:25 UTC

Linostar

2015-01-21 18:54:55 UTC

Patrick

2015-01-22 18:49:46 UTC

Linostar

2015-01-22 19:33:23 UTC

Patrick

2015-01-23 13:42:22 UTC

Linostar

2015-01-23 14:21:56 UTC

Patrick

2015-01-24 02:56:55 UTC

I am afraid not. Yes, it can be done with javascript, but if javascript is disabled, the code boxes will just look ugly.

How does the <pre> tag do this then? Would require a mediawiki extension then?

The button can be customized. If you can show me an example (e.g. a webpage or an image) of what you have in mind, it’ll be easier to make it look exactly like that.

Haven’t found a website, but the html code is simple.
<a href=just-to-make-it-look-blue>
<font size=-3>[select code]</font>
</a>
Here is a screnshot.
Screenshot:
{F27}

Linostar

2015-01-24 08:01:04 UTC

Patrick

2015-01-24 17:58:32 UTC

Patrick

2015-01-29 12:08:20 UTC

We needed to disable raw html (the <html> tag) for security reasons [otherwise evil javascript could steal admin cookies due to edits by non-admin users] and are now using the safer Extension:Widgets.

Therefore moved Template:CodeSelect - Whonix to Widget:CodeSelect - Whonix.

The Widget: namespace does not support mediawiki variables (such as {{{1}}}) directly, but also supports parameters. See:
Extension:Widgets - MediaWiki

See also example widget:
https://www.whonix.org/wiki/Widget:Share

And how to use it in an example template:
Template:Share - Whonix

Having said that… Does anything change? I guess we can still use your CodeSelect code if we adjust the parameter syntax?

Can we now somehow auto detect number of rows?

To manually enter the number of rows would be kinda cumbersome. If you look through the wiki, how often we are using the <pre> tag, if we were to change them all by hand and not forget updating that number each time the content is changed, that would be kind hard. So maybe, if it doesn’t work with special chars such as = as first char, could rows be auto detected?

Linostar

2015-01-29 12:26:23 UTC

Patrick

2015-01-29 12:38:08 UTC

Does not seem that widgets allow html/js code on their own when raw html is disabled, as in your:
https://www.whonix.org/wiki/Widget:Share

Not sure I understand. The raw html is not correctly rendered on that https://www.whonix.org/wiki/Widget:Share page. But the calling page Template:Share - Whonix shows the correctly rendered html that is based on the widget page’s html code.

Perhaps you should enable tags only in template pages instead? (if that’s possible)

Unfortunately, that’s not possible. (Not saying it’s impossible, but would require writing a mediwiki extension for that and html extensions getting right seems very hard - judged by all the attempts that were made in past.)

As for detecting row numbers, the best I can come with is the following: if javascript is enabled, detect row numbers and adjust the height accordingly using js; if js is disabled, then display the textarea with fixed row number (6 for example) and vertical scrolling arrows if number of rows exceed 6.

How does that sound?

Better but still impractical.

If you go to Permission error - Whonix - be careful with that one - and enter <pre> as search term, then continue and look at the results… And then abort… You see how many times we are using that tag. Going through all of them would be a lot work and I am sure editors would be confused and/or mess up entering correct row number.

Linostar

2015-01-29 13:41:43 UTC

! In T93#1312, @Patrick wrote:
Does not seem that widgets allow html/js code on their own when raw html is disabled, as in your:
https://www.whonix.org/wiki/Widget:Share

Not sure I understand. The raw html is not correctly rendered on that https://www.whonix.org/wiki/Widget:Share page. But the calling page Template:Share - Whonix shows the correctly rendered html that is based on the widget page’s html code.

Perhaps you should enable tags only in template pages instead? (if that’s possible)

Unfortunately, that’s not possible. (Not saying it’s impossible, but would require writing a mediwiki extension for that and html extensions getting right seems very hard - judged by all the attempts that were made in past.)

My mistake. I assumed the widget would render correctly on its own page like template pages do. Since the widget can render html tags correctly, I’ll make the necessary changes so the ‘code’ parameter is replaced properly in the widget.

As for detecting row numbers, the best I can come with is the following: if javascript is enabled, detect row numbers and adjust the height accordingly using js; if js is disabled, then display the textarea with fixed row number (6 for example) and vertical scrolling arrows if number of rows exceed 6.

How does that sound?

Better but still impractical.

If you go to Permission error - Whonix - be careful with that one - and enter <pre> as search term, then continue and look at the results… And then abort… You see how many times we are using that tag. Going through all of them would be a lot work and I am sure editors would be confused and/or mess up entering correct row number.

I think you misunderstood me a bit. By making a default value for the number of rows, it means we need not to insert the row number manually in the widget tag. If javascript is enabled, the default value will be overrided based on the height of the element. Otherwise, vertical scrollbars (if js is disabled) will show to allow the users to scroll within the CodeSelect element.

Linostar

2015-01-30 11:45:54 UTC

Patrick

2015-02-01 04:57:26 UTC

Without javascript, it’s too much scrolling. Just two lines are visible. The rest needs to be scrolled.

Did you remove the configure lines number feature?

Here is an good example, on how we are using the <pre> tag:
Security Guide - Whonix

I am afraid to say, manually counting the number of lines, adjusting that for the whole wiki looks like too impractical, because that would be too much work. And fail, as soon as the content within that tag is changed, I am sure wiki editors would forget the update the number of lines.

Could the line number without javascript feature be implemented using a mediawiki extension?
Manual:Developing extensions - MediaWiki

We could look if we find a similar extension that implements a different <tag> and see how they implemented that. Surely it could then be “gifted”?

Not sure if that would be overkill / too much work.

Linostar

2015-02-01 07:07:03 UTC

Linostar

2015-02-03 11:25:23 UTC

Patrick

2015-02-03 16:47:41 UTC

Linostar

2015-02-03 17:52:21 UTC

Unfortunately, it is necessary to keep it. Without it, any code that contains a ‘=’ will face a problem.

For example, if you have a this code:

a=15;
print(a);

If you write

print(a);}}```

the template will think that **a** is a template variable, and everything after the '=' sign will be treated as the value of this variable. And since there is no variable called **a** anywhere in the template code I've written, no text will appear in the code box.

tldr;
Attributing a parameter name (such as **code**) is necessary so any '=' is properly escaped and not considered as part of the template code.

Patrick

2015-02-03 18:06:40 UTC

Okay, alright.

As a personal matter of taste, instead of writing the following style (a)
{{CodeSelect|code=sudo apt-get update}}
I prefer to write the following style (b)
{{CodeSelect|code=
sudo apt-get update
}}
Because then I can abstract the “markup magic”, forget about it, and just concentrate on what I really wanted to write.

There is no difference at the moment and I guess I am lucky it is parsed that way.

Currently doing a beta test here:
Security Guide - Whonix

There is one issue. When writing this (b) [but same as (a)], i.e. just using a single line, with javascript enabled…
{{CodeSelect|code=
sudo apt-get update
}}
Within the CodeSelect area, it adds an extra empty line after “sudo apt-get update” at the bottom. Can this be fixed?

Also there is a bit much space between
normal text area and
CodeSelect area
and next normal text area.

Could you fix that as well please?

Linostar

2015-02-03 20:37:32 UTC

Patrick

2015-02-03 23:16:10 UTC

Linostar

2015-02-04 21:37:48 UTC

Linostar

2015-02-09 14:26:49 UTC

Patrick

2015-02-09 14:43:56 UTC

Linostar

2015-02-09 18:13:10 UTC

Patrick

2015-02-10 01:56:39 UTC

Linostar

2015-02-10 07:45:06 UTC

Patrick

2015-02-10 08:09:14 UTC

Linostar

2015-02-10 09:01:45 UTC

Patrick

2015-02-10 10:20:07 UTC

Linostar

2015-02-10 10:43:44 UTC

Patrick

2015-02-10 11:38:27 UTC

Linostar

2015-02-10 12:28:40 UTC

Patrick

2015-02-10 12:35:09 UTC

Patrick

2015-02-10 13:11:40 UTC

Linostar

2015-02-10 13:19:53 UTC