Page MenuHomePhabricator

Unstable interface bug in the Translate form
Closed, ResolvedPublic

Description

For several weeks, I see an annoying bug: when you click on the link to "translate" link in the translatable page, and then begin to translate any item, the translation form opens in a corrupt view:

I don't see suggestions ;(

After page refresh, this restored to good view, until the next translatable page:

OS: Win7,
Browser: Yandex-Browser (based on Chromium)
Site: Meta-wiki

Another example from translatewiki.net:


See also: T112047: Special:ManageTranslatorSandbox fails to finish loading

Details

Related Gerrit Patches:
mediawiki/extensions/Translate : masterFix typo in previous commit
mediawiki/extensions/Translate : masterTemporary fix for broken infocolumn (part 2)
mediawiki/extensions/Translate : masterTemporary fix for broken infocolumn

Event Timeline

Kaganer created this task.Sep 7 2015, 12:38 PM
Kaganer assigned this task to Pginer-WMF.
Kaganer raised the priority of this task from to Needs Triage.
Kaganer updated the task description. (Show Details)
Kaganer added subscribers: Kaganer, Amire80, Nikerabbit.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 7 2015, 12:38 PM
Kaganer updated the task description. (Show Details)Sep 7 2015, 12:40 PM
Kaganer set Security to None.
Kaganer updated the task description. (Show Details)

I have seen this myself once or twice on Chrome. Most likely related to the recent changes of async loading of resources or the changes to styles I did.

Probably related is that on translatewiki.net main page I sometimes see the buttons without the usual styles.

In both cases cache bypassing refresh will clear the issue.

I didn't bother reporting this because I though it was just a temporary glitch and I because it might be part of the screen corruption issues (parts of pages not redrawing) on Fedora 22 I am having a lot.

Nikerabbit removed Pginer-WMF as the assignee of this task.Sep 7 2015, 12:50 PM
Nikerabbit triaged this task as High priority.
Nikerabbit updated the task description. (Show Details)
Nikerabbit added a subscriber: Purodha.

From the duplicate report, it seems this might also affect JavaScript, not only CSS.

Nemo_bis updated the task description. (Show Details)Sep 11 2015, 10:35 AM
Nemo_bis added a project: JavaScript.
Nemo_bis added a subscriber: Liuxinyu970226.
Nemo_bis updated the task description. (Show Details)Sep 22 2015, 1:01 PM
demon added a subscriber: demon.Oct 22 2015, 4:46 PM

Not sure why this is tagged MW-1.26-release, it isn't bundled.

Nikerabbit added a subscriber: Stryn.

From the duplicate report, it might be related to localstorage being full (NS_ERROR_DOM_QUOTA_REACHED) and confirms it also affects JavaScript.

Not sure why this is tagged MW-1.26-release, it isn't bundled.

ResourceLoader definitely is. :)

Nemo_bis added subscribers: matmarex, StudiesWorld.

This seems to depend on the order in which CSS is loaded/applied.

.grid .column, .grid .columns {
    float: left;
    min-height: 1px;
    padding: 0 5px;
    position: relative;
}
.tux-message-editor .infocolumn-block {
    font-size: 12pt;
    background: #FCFCFC;
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    padding: 0;
    -webkit-transition: width 0.5s;
    transition: width 0.5s;
}

If the first block loads first, and the second later (position: absolute wins), everything is fine. If the order is reversed, see the screenshot.

demon moved this task from Backlog to To be fixed on the MW-1.26-release board.Nov 9 2015, 7:06 PM
demon moved this task from To be fixed to Backlog on the MW-1.26-release board.Nov 25 2015, 5:49 PM
demon moved this task from Backlog to To be fixed on the MW-1.26-release board.Nov 25 2015, 8:05 PM

If it will, then only by chance. The problem is missing dependency between the two modules with the stylesheets, or insufficiently specific CSS rules in the second one (if you can't or don't want to declare the dependency).

This seems to depend on the order in which CSS is loaded/applied.
If the first block loads first, and the second later (position: absolute wins), everything is fine. If the order is reversed, see the screenshot.

The first block is added with addModuleStyles. The second block is added with addModules. This sounds like ResourceLoader is not fulfilling the expectation of applying modules added with addModuleStyles first in all cases.

The first block ('jquery.uls.grid' in mediawiki/extensions/UniversalLanguageSelector) is added with addModuleStyles, but is *also* set as a dependency on like half a dozen of modules loaded with addModules or dynamically on the client-side. Due to T87871, that means it will be loaded twice. The second load probably happens after the second block ('ext.translate.editor').

jquery.uls.grid is not an explicit dependency of any module in Translate: the grid is used for basic page layout. It is dependency of some modules in ULS, because it is used for the dialogs that are only shown after a click.

It is not very large module, so loading it always with addModuleStyles could be done. But we got complaints in the past for not lazy-loading stuff, so I am hesitant to do it. T87871 is currently set to have low priority, so it seems we are stuck here.

jquery.uls.grid is not an explicit dependency of any module in Translate: the grid is used for basic page layout. It is dependency of some modules in ULS, because it is used for the dialogs that are only shown after a click.
It is not very large module, so loading it always with addModuleStyles could be done. But we got complaints in the past for not lazy-loading stuff, so I am hesitant to do it.

CC Performance-Team

It's not clear to me what the problem is here. I already explained what is causing this bug and how to fix it. Do you want me to submit a patch?

My worry is that if we implement your proposed fix (adding more specificity to the CSS rules), it will start chase game where we will keep finding more and more places where more specificity is needed (e.g. T112047) . Given that it is currently impossible to force the loading order of modules to test this systematically, that is slow and annoying process.

On the other hand, if ResourceLoader was changed, it would solve both double loading of styles and order of module loading for once and all.

Change 267676 had a related patch set uploaded (by Nikerabbit):
Temporary fix for broken infocolumn

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

Change 267676 merged by jenkins-bot:
Temporary fix for broken infocolumn

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

Change 267680 had a related patch set uploaded (by Nikerabbit):
Temporary fix for broken infocolumn (part 2)

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

Change 267680 merged by jenkins-bot:
Temporary fix for broken infocolumn (part 2)

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

Thanks for some refreshing water on the fire. :)

Storing thoughts from IRC:

The thing is that Translate adds addModuleStyles() on the special pages where it is needed, but ULS uses dependencies. Translate cannot do without addModuleStyles because that causes FOUC etc., so the options are

  1. wait a fix in RL
  2. sprinkle dependencies on Translate modules and double load the styles
  3. add specificity to CSS selectors

I did 3 hoping that 1 is not too far away. @matmarex thinks 2. would be more future proof.

Change 267851 had a related patch set uploaded (by Nikerabbit):
Fix typo in previous commit

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

Change 267851 merged by jenkins-bot:
Fix typo in previous commit

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

Should be fixed now?

I am considering keeping this open because I am not not too happy with the current solution and would like to switch to better one when possible.

Nikerabbit lowered the priority of this task from High to Low.Apr 20 2016, 1:33 PM
Nikerabbit edited projects, added Technical-Debt; removed Beta-Cluster-reproducible.
demon removed a subscriber: demon.Mar 9 2017, 9:38 PM
Nikerabbit closed this task as Resolved.Apr 6 2018, 2:18 PM
Nikerabbit claimed this task.

To my knowledge this has now been fixed in core.