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