This is an unforeseen side-effect of conversion to mediawiki-ui for ULS dialog. When it loads the styles (of course) apply to all pages.

I don't see any way to fix this, other than reverting this patch again, which would be sad. How long until MediaWiki really starts using oojs-ui/mediawiki-ui, because that would make this issue go away?

We could also update ULS to oojs(-ui), but per my understand that would require a major rewrite compared to simple changes that were needed for mediawiki-ui.

Can a3c63f1efc2e584dfe991e3803791cd03a54138e be reverted until this is fixed?

Like I already wrote, I'd rather not. It doesn't seem very severe to me.

@Nikerabbit One of the first things that is very obvious, Visual Editor sets the base font-size for its interface to .8em

.ve-init-mw-desktopArticleTarget {
    font-size: 0.8em;
}

The ULS tooltip takes root 100% as base, resulting in quite different interface sizes.
Echo does a bit different again.

Before we're going any further we should probably try to agree (across teams) on one way to handle default interface base sizes. It's very confusing to be facing same kind of elements at different scales in different places in the same view.

The OOUI blocker here is T97631: Change OOUI WikimediaUI theme to be optimized for font-size of 14px (0.875em×16px), instead of 12.8px (0.8em×16px), like MediaWiki's Vector skin.

@Etonkovidova reports that this also happens when focusing the search box on https://ca.wikipedia.org/wiki/Especial:Prefer%C3%A8ncies . Probably because ULS loads when an input is focused.

I would appreciate if the standard frontend styles that are provided for extension developers were actually usable.

But more constructively, reverting the patch in question at this point would be messy. I honestly cannot think anything else on our side than copying mediawiki.ui.button styles to ULS and renaming the classes, which brings us back to starting position of trying to get more close to the standards by using them (but look would be more consistent still).

I've experienced this only in (newest) Opera, not in Firefox. Haven't tested in other browsers. Please add relevant browser-support-* tag(s) as it seems not to be crossbrowser issue.

In T133114#2313279, @Danny_B wrote:

I've experienced this only in (newest) Opera, not in Firefox. Haven't tested in other browsers. Please add relevant browser-support-* tag(s) as it seems not to be crossbrowser issue.

Uh, no. It definitely happens in all browsers I have available to test, including Firefox.

In T133114#2314715, @Jay8g wrote:

In T133114#2313279, @Danny_B wrote:

I've experienced this only in (newest) Opera, not in Firefox. Haven't tested in other browsers. Please add relevant browser-support-* tag(s) as it seems not to be crossbrowser issue.

Uh, no. It definitely happens in all browsers I have available to test, including Firefox.

If it's true, then T135831: Clicking to any input on Special:Preferences in Opera triggers form change from standard form to MediaWiki UI which @matmarex merged, is not duplicate, because I do not experience that in Firefox (46.0.1, neither in previous versions)

In T133114#2314747, @Danny_B wrote:

In T133114#2314715, @Jay8g wrote:

In T133114#2313279, @Danny_B wrote:

I've experienced this only in (newest) Opera, not in Firefox. Haven't tested in other browsers. Please add relevant browser-support-* tag(s) as it seems not to be crossbrowser issue.

Uh, no. It definitely happens in all browsers I have available to test, including Firefox.

If it's true, then T135831: Clicking to any input on Special:Preferences in Opera triggers form change from standard form to MediaWiki UI which @matmarex merged, is not duplicate, because I do not experience that in Firefox (46.0.1, neither in previous versions)

Yeah, that does sound like a separate issue. The one as described in this task is cross-browser. (Off topic, but I can't reproduce that one, even in Opera.)

In T133114#2312804, @Nikerabbit wrote:

I would appreciate if the standard frontend styles that are provided for extension developers were actually usable.

The original MediaWiki UI implementation (the "mediawiki.ui.*" modules) is deprecated and not actively developed. The only reason it still exists is because it would take effort to remove all the usages, and obviously no one wants to volunteer to do such thankless work (and it is not a priority for any WMF team).

OOjs UI is recommended, actively developed, and as far as I can tell actually usable. Please try using it. :)

In T133114#2324478, @matmarex wrote:

The only reason it still exists is because it would take effort to remove all the usages, and obviously no one wants to volunteer to do such thankless work (and it is not a priority for any WMF team).

Is there any task about that?

Yes, T100270: Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core and its blockers.

How usable is OOjs UI in MediaWiki 1.25 (maybe soon 1.26)? As far as I know lots of development has happened since then and I worry trying to find what's compatible since then and now would be difficult. Also, is there way to just use the styles only, or does it need full rewrite of the interface to use it? We do not have time for big rewrites.

In T133114#2325332, @Nikerabbit wrote:

How usable is OOjs UI in MediaWiki 1.25 (maybe soon 1.26)? As far as I know lots of development has happened since then and I worry trying to find what's compatible since then and now would be difficult.

The basic things like buttons and textfields have been stable since ever. There shouldn't be any major differences between how they behave in MW 1.25 (OOjs UI 0.11.3) and 1.27 (OOjs UI 0.17.1), see the changelog: https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md. There were mostly a few styling changes.

Also, is there way to just use the styles only, or does it need full rewrite of the interface to use it? We do not have time for big rewrites.

No, since the styles depend on the DOM structure of the widget. But it's easy to replace individual interface elements with OOjs UI widgets without any "full rewrites", unless you did something crazy like concatenating together strings of HTML to build your interface. Here's an example commit that just replaces a few custom buttons in UploadWizard with OO.ui.ButtonWidgets: a3e26b8493dfae41e5d1ba5dedb6faabb86f168a.

Also the performance issues? Wasn't the splitting to smaller modules done only recently?

Anyway, I can give a shot to converting the radios and checkboxes to OOjs UI later this week, since that seems to be the part that causes problems.

Change 291753 had a related patch set uploaded (by Bartosz Dziewoński):
HTMLRadioField: Only add 'mw-ui' classes when needed

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

Change 291753 merged by jenkins-bot:
HTMLRadioField: Only add 'mw-ui' classes when needed

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