Page MenuHomePhabricator

Editing screen shouldn't re-shape or move after it is displayed
Open, NormalPublic

Description

The problem description:
I open the article to edit, click on some text, but the edit menu slowly pulls down in the meantime, and my click goes into that edit menu instead. The problem is particularly bad on Wiktionary, where articles are likely smaller, and on the busy systems where the menus load slower.

The proposed solution:
Make the space for the menu in the original document when it loads, so that no re-shaping will be taking place later.

Event Timeline

Yurivict created this task.Feb 4 2016, 5:37 PM
Yurivict raised the priority of this task from to Needs Triage.
Yurivict updated the task description. (Show Details)
Yurivict added a subscriber: Yurivict.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptFeb 4 2016, 5:37 PM

Hi @Yurivict. Please associate at least one code project with this task, otherwise nobody can find this task when searching in the corresponding project(s).
Exact steps to reproduce (classic wikitext editing? VisualEditor editing?) are also extremely welcome - see https://mediawiki.org/wiki/How_to_report_a_bug for more information.
Thanks.

Aklapper renamed this task from Editing screen shouldn't re-shape or move after it is displayed - this hurts productivity to Editing screen shouldn't re-shape or move after it is displayed.Feb 5 2016, 12:27 PM
Aklapper set Security to None.

Observing the problem in the classic editor, with options "Show the edit toolbar", "Enable enhanced editing toolbar" enabled.

Problem is especially bad in Chrome, better in Firefox. Might be due to the specifics of browser inner workings.

My suggestion is that the original DOM document should have the space allocated for all toolbars upfront, and JavaScript shouldn't cause any screen re-shaping later when it initializes them.

Krenair added a subscriber: Krenair.
GOIII added a subscriber: GOIII.Feb 5 2016, 11:19 PM

Observing the problem in the classic editor, with options "Show the edit toolbar", "Enable enhanced editing toolbar" enabled.
. . .

fwiw... the "classic" toolbar & editor is the default when only the Show the edit toolbar option is selected.

"WikiEditor" 'properly' replaces the classic toolbar only when Enable enhanced editing toolbar is enabled.

When both options are enabled, the classic toolbar is usurped by WikiEditor (not desirable; you should have one option selected or the other but not both at the same time).

You should also make sure 'Use live preview' further down on the same page of User: edit preferences did not get enabled somehow.

Change 290066 had a related patch set uploaded (by TheDJ):
Avoid reflow due to WikiEditor toolbar loading

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

TheDJ claimed this task.May 22 2016, 3:31 PM
TheDJ triaged this task as Normal priority.
TheDJ moved this task from Backlog to Doing on the WikiEditor board.

Nice. Noticed T135995 while testing.

Change 290066 merged by jenkins-bot:
Avoid reflow due to WikiEditor toolbar loading

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

TheDJ closed this task as Resolved.May 25 2016, 11:25 AM
TheDJ moved this task from Doing to Closed on the WikiEditor board.
TheDJ removed a project: Patch-For-Review.
TheDJ reopened this task as Open.Sep 18 2017, 9:15 AM

That patch only works if the old toolbar is enabled as well.. Since we are removing that soon, we should probably look at this again... We really need some unique CSS marker in the generated HTML, to denote that WikiEditor will be loading.

TheDJ added a comment.Sep 19 2017, 1:05 PM

Seems that Editpage is still a bit of a mess. Not easy to modify the HTML, without reimplementing the entire form...
Simple workaround would be to use OutputPage->addBodyClasses, to add editor-wikieditor or something..

TheDJ removed TheDJ as the assignee of this task.Nov 8 2017, 1:05 PM
TheDJ added a subscriber: TheDJ.

Unassigning, as I do not have plans to work on this right now.

happy5214 moved this task from Closed to Backlog on the WikiEditor board.Aug 4 2019, 11:35 AM