Possible solutions:

1. See if this can be done with existing events in VE
2. Add a new "toolbar shown" hook to VE
3. Change VE visual mode loading sequence to be like the source mode loading sequence (show a dummy toolbar), as in source mode we always show a dummy toolbar immediately. This is also similar to how VE loads on mobile.

Change 756969 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/VisualEditor@master] Desktop: Always show loading progress in a toolbar placeholder

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

Change 756970 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/skins/Vector@master] Use new ve.activationStart hook to hide header earlier when loading editor

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

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/184e59645e/w/

The above patches implement approaches 2 & 3 combined.

In T299907#7649375, @PatchDemoBot wrote:

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/184e59645e/w/

Per yesterday's conversations with @Esanders and @iamjessklein, we see value in the changes Ed is proposing.

Next step(s)
The next step is to experiment with refinements to the experience. We agreed the current implementation [i] feels a bit hectic/messy.

A couple of ideas that surfaced yesterday:

• Remove the boarder from the loading "cylinder"
• Try the loading + spinner icon that's used on mobile

i.

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/dd823293fa/w/

The updated patch delays showing the VE toolbar until the load is fully complete, so that we never show the loading bar over a greyed out toolbar.

Demonstration of the changes from T299773 and T299907, in a few scenarios:

Notes:

• Scenario 2 shows off the scrolling change from T299773
• Scenarios 4 and 5 feel a bit choppy (both before and after), but I guess we're not really trying to optimize them right now

Note that in your "before" demos, the toolbar always appears instantly when you press [edit]. This is only the case because the VE code is already in memory which only usually happens the second time you load VE in a page session. More realistically you would see the progress bar get about half way before the toolbar dropped in, which is one of the inconsistencies this patch fixes.

Change 756969 merged by jenkins-bot:

[mediawiki/extensions/VisualEditor@master] Desktop: Always show loading progress in a toolbar placeholder

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

In T299907#7707962, @Esanders wrote:

Note that in your "before" demos, the toolbar always appears instantly when you press [edit]. This is only the case because the VE code is already in memory which only usually happens the second time you load VE in a page session. More realistically you would see the progress bar get about half way before the toolbar dropped in, which is one of the inconsistencies this patch fixes.

Yeah, good point. It was easier to get consistent screen recordings if I didn't reload the page before each one, which had this result, and which is not completely realistic. I guess I've shown the best case for the "before" demos.

Change 756970 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Use new ve.activationStart hook to hide header earlier when loading editor

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

For Jess!

In T299907#7705956, @matmarex wrote:

Demonstration of the changes from T299773 and T299907, in a few scenarios:

Scenario	Before	After
	https://patchdemo.wmflabs.org/wikis/171abfbea6/wiki/Scoring_(cricket)	https://patchdemo.wmflabs.org/wikis/13a25daf4b/wiki/Scoring_(cricket)
1. Opening visual editor (at the top of the page)
2. Opening visual editor (section edit, middle of the page)
3. Opening visual editor (section edit, bottom of the page)
4. Switching from 2010 wikitext editor to visual editor
5. Opening 2017 wikitext editor

Notes:

• Scenario 2 shows off the scrolling change from T299773
• Scenarios 4 and 5 feel a bit choppy (both before and after), but I guess we're not really trying to optimize them right now

Thanks @matmarex for this. I have tested and all Scenarios play out as expected(i.e the After column).

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/dd823293fa/w/

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/184e59645e/w/

Just to clarify, the solution you chose uses the loading bar as an interstitial to pace the load appropriately. This solution works for me.

I think that the loading bar component is still being worked on, so I would say that this is in a good place to ship and when/if we have an updated component, we can file that as a separate ticket to be worked on.