Page MenuHomePhabricator

Edit window hardly usable once dynamically restyled.
Closed, ResolvedPublic

Description

Various MediaWiki instances make it hard to me to make changes since the edit window is severely impaired having strange fonts.

Adding
textarea { font-family:monospace }
to the personal commons.css sometimes helped but not always. Now, on a slow computer, I saw the edit window appear monospaced immediately after the change to common.css, only to watch it being garbled to something hardly readaly immediately thereafter.

I suggest to stop using scripts to mess around with things users already set the way they want it. KISS!


Version: 1.23.0
Severity: minor

Details

Reference
bz61746

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:00 AM
bzimport set Reference to bz61746.
bzimport added a subscriber: Unknown Object (MLST).

What are exact steps and settings to reproduce the problem?
Any public testcase?

Since users personal commons.css data are involved, there cannot be a public test case.

Steps to repoduce are mentioned above. More elaborate:
0. Use a browser with JavaScriping enabled, as is the most common stting.

  1. Create a user, if you have none.
  2. Add " textarea { font-family:monospace } " to the users commons.css
  3. Edit a page. You will find the edit window not styled monospace as one would expect.
  4. Switch JavaScript on. Reload edit page. It is styled as expected.

Clear enough?

Since users personal commons.css data are involved, there cannot be a public test case.

Steps to repoduce are mentioned above. More elaborate:
0. Use a browser with JavaScriping enabled, as is the most common stting.

  1. Create a user, if you have none.
  2. Add " textarea { font-family:monospace } " to the users commons.css
  3. Edit a page. You will find the edit window not styled monospace as one would expect.
  4. Switch JavaScript off. Reload edit page. It is styled as expected.

Clear enough?

(In reply to Purodha Blissenbach from comment #3)

Since users personal commons.css data are involved, there cannot be a public
test case.

In comnment 0 you mentioned personal commons.css for working around the bug, not for reproducing the bug.
Which MediaWiki version is run on those "various instances"?

Could you please attach a screenshot that shows the problem?
Which MediaWiki theme(s) was this tested with?

Screensht from translatewiki.net - textarea is styled using a proportional font.

Attached:

twn-O2P0.png (627×676 px, 90 KB)

Misunderstanding: I tried to style "textarea" via commons.css as a workaround. It did NOT work. (Once the CSS was applied, a JavaScript changed the style. Disabling JavaScripts avoided restyling and left the textarea untouched, but cannot be a working solution)

Most "various instances" are pretty recent, such as tests freshly pulled from git this year, or translatewiki.net - all with the vector skin. Omegawiki exhibits the problem, too, but is not very recent: MediaWiki 1.21.1 (df12d1d)

See https://translatewiki.net/w/i.php?title=User:Purodha/common.css&action=edit
If I leload that page via a throttled connection (disallow browser to load more than one file simultanously) I can see the edit window appear monospaced first, then proportional a moment later. See attached screenshot.

I also tried incubator, wikidata, and de.wikipeda just a minute ago. They do not seem to have the problem any more, despite empty commons.css / vector.css in some instances. This may point to a script specific to translatewiki.net and Omegawiki, or to a script that is usually not enabled by default, but is at least on these two. Also possibly, the script is activated due to my user settings such as gadgets. Im going to further investigate the latter idea and report, when done.

Does not occur any more with more recent versions of MediaWiki.

> setting to solved.