Page MenuHomePhabricator

Grammatical features field is now right-aligned
Closed, ResolvedPublic3 Estimated Story PointsBUG REPORT


When editing, the text in the grammatical features field is now right-aligned instead of left-aligned.


After clicking edit on

gf1.png (229×1 px, 23 KB)

After clicking into the field:

gf2.png (200×1 px, 21 KB)

Event Timeline

Tentatively tagging OOUI, since I don’t think we’ve touched the relevant code in WikibaseLexeme recently.

The last OOUI update was in 1.36.0-wmf.35, and apparently included fixes for two TagMultiselectWidgets issues (T277177 and T230066), and Wikidata is currently on wmf.35 and still has the issue, so I think it’s likely that this is caused by some OOUI changes. (That’s not to say that I’m blaming OOUI – maybe we’re doing something in WikibaseLexeme that has always been incorrect but just happened to work out so far.)

Lydia_Pintscher changed the subtype of this task from "Task" to "Bug Report".
Lydia_Pintscher moved this task from Incoming to Unconnected Stories on the Wikidata-Campsite board.
noarave set the point value for this task to 3.
noarave removed Final Story Points.
Michael added a subscriber: Michael.

Unclaiming this until I actually have my dev-environment in a state where I can work on it

To make it even more fun, in RTL languages it's left-aligned

image.png (208×934 px, 21 KB)

Also, shouldn't the gloss editor have a bit of margin? Anyway...

This is very likely caused by changed in ooui (there are a lot of them touching position of input element recently in TagMultiselectWidget) (T276483: TagMultiselectWidget always puts input on separate line after line 1 for example)

The problem is that the input element is before the options while it should be the opposite:

image.png (76×740 px, 7 KB)

I don't know what has caused it to behave like that (the easy ones look fine) yet but I'm investigating.

It's a bit hard to test it but reverting would fix the issue. I'm sure this is an upstream problem

It's a bit hard to test it but reverting would fix the issue. I'm sure this is an upstream problem

I can confirm that reverting to the commit right before and using those build artifacts in mediawiki fixes the bug described in this issue.

I'd rather fix this downstream. The upstream behaviour is correct and not broken.

This looks wrong:

 * @protected
onChangeTags: function () {

There is no call to the parent method.

Change 680306 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/extensions/WikibaseLexeme@master] Call the parent on onChangeTags as well

Change 680306 merged by jenkins-bot:

[mediawiki/extensions/WikibaseLexeme@master] Call the parent on onChangeTags as well