Page MenuHomePhabricator

Eliminate call to $.getVisibleText() in ve.init.mw.Target.prototype.onNoticesReady
Closed, ResolvedPublic8 Story Points

Description

Paul Irish: "it requires a very heavy recalculate style because it's using the :hidden selector. You should use your own logic to compute visibility that doesn't rely on getComputedStyle()."

It looks like the reason for this is T45013. Is the client-side hack still needed? Can enwiki's system be reformed?

Event Timeline

ori created this task.Jan 23 2015, 6:33 AM
ori raised the priority of this task from to High.
ori updated the task description. (Show Details)
ori added a project: VisualEditor-Performance.
ori added subscribers: ori, Catrope, Krinkle, Jdforrester-WMF.
Restricted Application added a project: VisualEditor. · View Herald TranscriptJan 23 2015, 6:33 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Can enwiki's system be reformed?

Sure. But we've been ignoring it because it's a large piece of work without high-priority value (new feature in MediaWiki core re-implementing community template hacks on one wiki).

Brief backstory:

MediaWiki core has an edit notice system. It's configurable by local wikis using the namespace prefix "Editnotice". E.g. MediaWiki:Editnotice-0 applies to the entire main namespace (NS_MAIN=0) and MediaWiki:Editnotice-4-Calendar applies to the "Project:Calendar" page (NS_PROJECT=4).

English Wikipedia community (and a few other wikis that copied this system) want to make this more discoverable and thus "created" all the namespace-wide pages with placeholders outputting a link to "create" the notice (which effectively exists already). This link is hidden by default for regular users using site-wide custom CSS. And then community elected admins (who have the ability to create the individual pages) have a shared stylesheet (Group-sysop.css) that sets display: block; on them.

For regular users using the plain wikitext editor via EditPage (action=edit), the html for the "create" link is output as being an edit noticed, but because it's display:none, it is effectively not present.

In VisualEditor, the edit notices are consumed from the EditPage API as an array of one or more notices. On English Wikipedia there is always an edit notice, and it's non-empty (it contains html). However depending on the stylesheets loaded, it may or may not be intended to be made visible.

The work-around I came up with is to write the jquery-getVisibleText plugin, and use that to determine whether a notice is visually "empty" and filter those out. This because our interface treats notices as separate widgets and displaying an empty one would result in the interface drawing a rectangular box with close button that looks broken.

Jdforrester-WMF edited a custom field.
Jdforrester-WMF edited a custom field.Feb 2 2015, 7:46 PM

Change 200654 had a related patch set uploaded (by Krinkle):
mw.Target: Remove visible text filter for edit notices

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

Change 200655 had a related patch set uploaded (by Krinkle):
mw.Target: Defer parsing of edit notices to MWNoticesPopupTool

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

Change 200654 merged by jenkins-bot:
mw.Target: Remove visible text filter for edit notices

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

Change 200655 merged by jenkins-bot:
mw.Target: Defer parsing of edit notices to MWNoticesPopupTool

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

Jdforrester-WMF closed this task as Resolved.Mar 30 2015, 8:26 PM
Jdforrester-WMF edited a custom field.
Jdforrester-WMF moved this task from Polish to Done on the VisualEditor 2014/15 Q3 blockers board.
Jdforrester-WMF moved this task from Bug Fixes to Q4 on the VisualEditor board.Mar 31 2015, 1:57 AM