Page MenuHomePhabricator

Long delay when typing in WikiEditor on pages that contain RLM / LRM
Open, LowPublic

Description

Some editors (incl myself) are experiencing long delays when typing into the WikiEditor edit window, in some pages, on various wikis.
I.e. We type a string of characters, and it takes a full second or more before the text appears.
We can reproduce in Firefox 48 and Chromium 51 (but not in Chromium 37) on Linux, Chromium 52 on Windows 10, and Firefox 47 in OSX, but not in Chrome 54 in OSX.
Logged-out as well as logged-in.
Test case 1: https://en.wikipedia.org/w/index.php?title=Thomas_Jefferson&action=edit
Test case 2: https://meta.wikimedia.org/w/index.php?title=Mailing_lists/Overview&action=edit
Taking the text from that article, and pasting it into certain pages at metawiki or mediawiki, has the same result, but not consistently.
There's slightly less of a delay at [[w:en:Barack_Obama]] (100k bigger), so it's probably not directly related to text length.
Someone's testing indicated a correlation with page-protection, but I can't confirm that.
Various reports say it has been a problem for a few weeks.

@ori noted in IRC regarding Firefox:

it looks like there is a paint / layout event on every keystroke

Event Timeline

I can reproduce this in Firefox even with JavaScript completely disabled.

This problem happens to me with Chrome 52 or Firefox 48 on Windows 10. I tried the following but none of them helped the problem:

  • Changed skin from Vector to Modern
  • Logged out and edited [[w:en:Kentucky]]
  • Disabled all my scripts in common.js
  • Disabled any beta features
  • Disabled all editing-related gadgets
  • Bypassed the cache

I think I have narrowed it down to the presence or absence of the left-to-right mark (LRM) in the page. The LRM is an invisible control character that indicates the directionality of adjacent text.

I can demonstrate this. Try typing into the textarea of each of the pages below in one of the affected browsers (Firefox, Chrome 51, etc.):

Typing on the page with the LRM is much more sluggish.

The mark is outputted to make sure the tooltip text for the block duration in block log entries has the right directionality. The tooltip text is always in English, ostensibly to help visitors from other wikis who can't read the content language. The relevant code is in BlockLogFormatter.php, L55-59.

I18n guidelines from the W3C indicate that using RLM / LRM characters in HTML to set directionality is valid, but largely obsolete in HTML5, where you can use the dir attribute instead.

So this is an upstream bug, and I'll make sure that it is reported. But I think we can evade it in MediaWiki by using the dir attribute instead, or by getting rid of the non-localized tooltip text, since (AFAIK) it's not a pattern we use elsewhere.

The BlockLogFormatter LRM code instead of dir was added (in a different file, later moved) in 2013: rMWea02cda0d695: Tweak Special:Log/block for supporting RTL wikis.

I'm afraid we use LRM/RLM more widely than that. Search the codebase for "getDirMark" and "getDirMarkEntity". Also search the localisation messages for "‎" / "‏" or "&lrm;" / "&rlm;". We probably can replace each of those with <span dir=ltr/rtl> wrapped around the word, but it's not going to be trivial; for the localisation messages we'd have to start parsing the wikitext in many of them.

Filed upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1296050

Chrome / Chromium 54 (the current dev channel release) does not appear to be affected, so I haven't reported it there. But it seems like some of the more recent reports on https://bugs.chromium.org/p/chromium/issues/detail?id=237433 were related to this issue.

ori renamed this task from Long delay when typing in WikiEditor on certain pages to Long delay when typing in WikiEditor on pages that contain RLM / LRM.Aug 17 2016, 6:46 PM

I'm afraid we use LRM/RLM more widely than that. Search the codebase for "getDirMark" and "getDirMarkEntity". Also search the localisation messages for "‎" / "‏" or "&lrm;" / "&rlm;". We probably can replace each of those with <span dir=ltr/rtl> wrapped around the word, but it's not going to be trivial; for the localisation messages we'd have to start parsing the wikitext in many of them.

Hrm, right. But it sounds like changing WikiPage.php, L2763 (not BlockLogFormatter.php, as I had incorrectly indicated earlier) might be enough to address the vast majority of cases.

Change 305388 had a related patch set uploaded (by Ori.livneh):
(WIP) Use a dir attribute instead of RLM/LRM control character in protect notices

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

I can demonstrate this. Try typing into the textarea of each of the pages below in one of the affected browsers (Firefox, Chrome 51, etc.):

Both are similarly sluggish for me in Chrome 52 (the current public version on Windows 10).

Something has fixed this issue in the meantime. A particular page where I had this problem isn't demonstrating the sluggishness I saw before.

I'm also on Chrome 53 and Firefox 49 now, so maybe browser updates made a difference?

Change 305388 abandoned by Ori.livneh:
Use a dir attribute instead of RLM/LRM control character in protect notices

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

I can no longer reproduce this problem on Chromium 55. I can still reproduce on Firefox 50. (Using the test cases from T143182#2561436, on Windows 10.)

I can demonstrate this. Try typing into the textarea of each of the pages below in one of the affected browsers (Firefox, Chrome 51, etc.):

I cannot reproduce on Chromium 53.0.2785.143 either, but as you mentioned

some of the more recent reports on https://bugs.chromium.org/p/chromium/issues/detail?id=237433 were related to this issue.

so we might want to test a longer textarea too.

I guess realistically speaking this is low priority? If anyone can still reproduce...