Page MenuHomePhabricator

Preference section "Internationalisation" balloons after clicking "More language settings"
Closed, ResolvedPublic

Description

Initially the page renders as follows:

There is no immediate FOUC or anything like that. When clicking "More language settings" the following happens:


Details

Related Gerrit Patches:

Event Timeline

Krinkle created this task.Apr 19 2016, 9:54 PM
Restricted Application added subscribers: TerraCodes, Aklapper. · View Herald TranscriptApr 19 2016, 9:54 PM

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.

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.

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

Arrbee added a subscriber: Arrbee.May 20 2016, 3:22 PM

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.

Jay8g added a subscriber: Jay8g.May 21 2016, 6:50 AM

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.

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)

Jay8g added a comment.May 22 2016, 5:40 AM

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

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

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?

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.

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

matmarex claimed this task.May 30 2016, 3:05 PM

While you're working to switch ULS to another system for its interface, this should fix the immediate issue exposed by loading the deprecated styles.

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

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

matmarex closed this task as Resolved.Jun 1 2016, 12:51 PM
matmarex removed a project: Patch-For-Review.