Alternatively, you could change the home page to the program's interface e.g. 127.0.0.1:7657 for I2P and start the browser with a script that creates a popup box using zenity or similar that tells the user the information.

merged into T809

Please reference

I don't know about running multiple Tor Browser's in parallel, but as
far as this environment variable is concerned, there won't be an issue
most likely.

The starter script of the alternative TBB instance could overwrite this

global, default environment variable.

The starter script of the alternative TBB instance could overwrite this
global, default environment variable.

I realized the homepage was set by an environment variable.

https://www.whonix.org/wiki/Dev/mediawiki#pre_tag_with_white_spaces

Great! Updated the wiki and documented here:

Replacing the | with {{!}} will render a | as expected. {{!}} is a "magic word" to Mediawiki, and it converts it to a pipe character.

Try making the opening tag <pre style="white-space: pre-wrap;"> instead of normal <pre>. There are a number of other wrapping/whitespace options if that doesn't work for what you need.

Closeable.

Closeable or anything left to do here?

Yes.

In T93#1816, @Patrick wrote:

What about moving [select code] inside the codebox? Is that even possible? Optically non-ideal, but in my opinion still better than the gap. Users who manually select select all, would they also select the text [select code] or could that be made exempt?

Okay, I see. So without having this feature natively supported by the skin or even mediawiki itself, there is no way?

Making only the lines before a CodeSelect shorter is not possible, because you can't know what element comes next or before in css. Making all lines shorter is possible perhaps, but will likely break the layout of other elements and the page.

Could it be done using https://www.whonix.org/wiki/MediaWiki:Common.css or the theme?

Nope. Controlling something outside the widget is not possible from inside the widget, especially when the lines outside are put in <p> element, which is an element that does not possess a width attribute.

To use less space between text and [select code], I was thinking to introduce some "invisible table" in the whole textarea. Normal text lines get the left 95% of space. And [select code] on the right gets the rest 5% (or how little) space.

You mean you want [select code] link inside the box instead of outside?

Looks better. Yes. Makes sense.

In T93#1727, @Patrick wrote:

It looks better.

Do you think the extra spaces can be further reduced?

See:
https://www.whonix.org/wiki/Security_Guide#Updates
(Between "Should look similar to this." and the next code block there is too much space for my taste.)

It looks better.

I have decided to give it another chance, and got some results. I found that the problem wasn't in the <div> tags, but because of the <textarea>. It turns out that <textarea> has a default margin-bottom value of 10px. I changed that value to 0, which shortened the distance between the CodeSelect box and the line(s) after.

In T93#1398, @Patrick wrote:

Please read this security advice about editing MediaWiki:Common.css:
https://www.whonix.org/wiki/Dev/CSS

Then... Perhaps you could make the required css changes on the https://www.whonix.org/wiki/MediaWiki:Common.css page? I'd speculate, that you have a lot more freedom there.

And if all cords break, I think using mediawiki skins (we are using this one: https://github.com/OSAS/strapping-mediawiki which is open source) one has an almost unlimited options for customization?

Please read this security advice about editing MediaWiki:Common.css:
https://www.whonix.org/wiki/Dev/CSS

Within the CodeSelect area, it adds an extra empty line after "sudo apt-get update" at the bottom. Can this be fixed?

Fixed.

As a personal matter of taste, instead of writing the following style (a)

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

Awesome, nice and simple fix!

I was too blind to see the most obvious solution! No need to use mediawiki extensions even.

The problem is that mediawiki doesn't allow full access (or any access) to the window object in javascript. That's why I am unable to select the contents of an element unless it is an input text or a textarea, both containing an embedded selecting function and don't need to use the window object.

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

I've added the auto-resizing feature. You can test with js enabled/disabled to see how it would look on:
https://www.whonix.org/wiki/Translatetest5

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 https://www.whonix.org/wiki/Template:Share shows the correctly rendered html that is based on the widget page's html code.

Perhaps you should enable <html> 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.)

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

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

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.

Looks perfect.

In T93#1114, @Patrick wrote:

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?

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

In T93#1110, @Patrick wrote:

Can the number of rows be auto detected?

Can the number of rows be auto detected?

I made a change that gets '=' to display properly instead of being a treated as a part of the template. As consequence, the new syntax for the template has become:
{{CodeSelect|number_of_rows|code=actual_code_goes_here}}

Nice template!

I managed to do it. I found that there are some constraints on javascript code in wikimedia and the normal selecting methods don't work. As a workaround, I had to substitue the <pre> element with a <textarea> element and changed the style of the latter to look like the former.

Yes, you are now wiki admin.

In T93#1046, @Patrick wrote:

Javascript is enabled and the test popup is working. Security is not an issue here. We are using FlaggedRevs extension. New edits won't be shown to regular users by default as long as admins have not confirmed these changes.

Javascript is enabled and the test popup is working. Security is not an issue here. We are using FlaggedRevs extension. New edits won't be shown to regular users by default as long as admins have not confirmed these changes.

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"

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.

Forgot to say... This shouldn't make things worse for users that have javascript disabled or using browser that don't have that feature yet.

Hey guys,
if we wait a while it might become more commonplace and then we could potentially get this to work.
there's api support within HTML5 called ClipboardEvent.
it's currently supported by Firefox only, but i'm hoping other browsers will add support.

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?

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