The sticky header hides when the VE interface is loaded, but only when it is fully loaded. It should hide earlier than that while VE is loading (as soon as the toolbar becomes visible)

In T293719#7441775, @Esanders wrote:

The sticky header hides when the VE interface is loaded, but only when it is fully loaded. It should hide earlier than that while VE is loading (as soon as the toolbar becomes visible)

I suspect we're just using the wrong hook. Are the VisualEditor lifecycle hooks documented anywhere?

I don't think so, but there aren't many hooks if you just search for mw.hook( '. You may want ve.activate instead of ve.activationComplete?

In T293719#7445312, @Esanders wrote:

I don't think so, but there aren't many hooks if you just search for mw.hook( '. You may want ve.activate instead of ve.activationComplete?

Looks like ve.activate runs too late. It runs the loading bar is at about 50%. There doesn't seem to be a hook meaning "we have begun loading". Should we add one? e.g. mw.hook.fire( 've.requested' ) ?

It should hide earlier than that while VE is loading (as soon as the toolbar becomes visible)

These two things are actually distinct, and it is more pronounced if you compare the first and second loads of the editor in a single session.

The toolbar becomes visible once the VE code has loaded, which for the first load is usually when the loading bar is ~50% as you observed. For the second load the toolbar should be visible immediately.

In both cases - the ve.activate hook should be roughly the correct timing for when the toolbar is drawn.

• Toolbar while in Editing Mode - This looks a bit unfinished now (in comparison the the full sticky header). I'd expect for the toolbar to extend to the width of the browser in some for and have an obvious overlay effect on top of any content that it's aligned with/overlapping.

• Toolbar transitions - this seems to be what @Esanders is referencing, but if not, I thought I would just share my concerns. First there's quite a delay when transitioning modes. Before a full transition is made, there's an interim flicker.

• Performance - I'm not sure if this is just an issue with everything not being on production, but the whole experience is very slow.

• Positioning - It feels wrong to be zoomed to the top of the page (which in this case was the template and not even the text) after moving into visual editing view. I would expect my page scroll to be maintained. The larger issue here is just not seeing where the cursor is and therefore not knowing where you are in the editing process.

NB most articles on the live sites don't being with inline templates, so the cursor would be moved to the start of the first actual paragraph where it will be slightly more visible due to it blinking and not greyed-out:

https://en.wikipedia.org/wiki/Cat?veaction=edit

Performance - I'm not sure if this is just an issue with everything not being on production, but the whole experience is very slow.

Do you mean specifically with the editing aspect, or something about the entire sticky-toolbar-experience?

Do you mean specifically with the editing aspect, or something about the entire sticky-toolbar-experience?

yes, specifically transitioning after clicking the buttons on the sticky, so perhaps that is actually an editor issue @DLynch

yes, specifically transitioning after clicking the buttons on the sticky, so perhaps that is actually an editor issue @DLynch

I guess I'd say to try editing the same article in non-beta and see whether you feel that way. Granted, that'd not narrow it down between it being some issue brought out by the sticky toolbar and general beta-cluster slowness, but...

QA Review Status:

1. When you navigate away from a page in read mode and get back to it again, it retains the scroll position to the previous point.

DECISION: no action needed. We decided that, it actually works as expected since readers probably would want to get back to the position of the article where they left off before navigating away.

2. On production, when you get back to a page where you opened the User Menu drop down before navigating away, it keeps the drop down open.

ACTION: Filed as: T295085.

3. Every time I open VE for a page the item "Upload media" and "Translations" under User Menu is getting duplicated.

ACTION: Filed as: T295082.

4. When I click on Edit button on our regular fixed header, and then click back to go to the read mode, it takes me to the top of the article but when I click on the Edit button on the sticky header and then back to the read mode it takes me back to the point where the scroll position was. which is not consistent experience from two types of headers.

DECISION: We realized even though it seems inconsistent they are working as expected in their own way, for the same reason as point#1.

5. When you change the preferences for your editor, the icon is not showing up correctly on the sticky header.

DECISION: no action needed for now; icons will be addressed in T289723.

6. Is it possible to open the editor on the same position where they clicked on edit on the sticky header like it does when section editing? It seems it already does remember the position when I hit Back button to get back to read mode. I think the experience should be same both ways, either move to the top always, or to a specific position.

Also, when you publish a change, it does not scroll to the position where the edit was made but rather to the position where you clicked on Edit on the sticky header.

ACTION: Filed as: T295089 and T295094.

@Ryasmeen thanks for your thorough review here

In T293719#7499121, @alexhollender wrote:

@Ryasmeen thanks for your thorough review here

: ) Thanks @alexhollender!

To bring further closure to this task, the investigation we did as part of it proved to be a valuable input to creating the requirements that will inform how we will initially approach introducing editing functionality within the sticky header.

See T296910: [Implementation] Introduce editing functionality to sticky header.