Brackets UI shifts upward (showing slight gap) during reload

[peterflynn]

1. Launch Brackets
2. Hit F5

Result:
After you hit F5, the UI shifts upward 10-15 px. About a second later (or a little less), the UI disappears and then reloads, positioned correctly again.

Expected:
No jump visible during reload.

This appears to be due to the new menu-item code (#6484), perhaps interacting with the new Aero dark shell: once all menu items have been removed, the menu bar is hidden, making the content area taller. The window immediately repaints even though CEF hasn't had time to process the resize yet, so the pixels shift upward & leave a gap. The app remains so bogged down with the reload that it never gets a chance to repaint more correctly before the reload completes.

CC @lkcampbell & @redmunds & @JeffryBooher

[redmunds]

This is because Reload (both with and without Extensions) removes all native menus (so they get reloaded cleanly).

[lkcampbell]

@peterflynn or @redmunds, I don't have a Windows machine to test this, but I have a test fix to try if one of you can test it for me:

https://github.com/lkcampbell/brackets/tree/fix-6523

I put a one second delay between the menu removal and the reload. I know, it's too long, but I wanted to test with a longer delay to see if it worked before I decreased the delay.

[JeffryBooher]

FWIW -- I built a version of the shell without the Dark UI and this issue still reproduces so this doesn't require the Aero Dark shell to reproduce -- this occurs with the Windows default UI appearance as well.

@lkcampbell I tested your change and it still reproduces. The menu bar disappears and the content sifts up and there is a longer delay before it is reloaded so it's more noticeable with that change.

[lkcampbell]

@JeffryBooher thanks for testing it. It was worth a try :).

[lkcampbell]

@JeffryBooher, is there an event in the windows app shell that occurs when the last menu or the menu bar is removed, where we could do a repaint?

[JeffryBooher]

There isn’t a message per se but we do get messages when the frame changes which is what happens when menu items are added or removed. What did you want to repaint?

[lkcampbell]

I suppose it would be a repaint of the content that gets shifted when the menu bar disappears. Wouldn't want to do it on every menu item removal though, that would probably be a performance hit. It should just repaint when the last menu disappears, taking the menu bar along with it.

[JeffryBooher]

Technically the best way to solve this is to disable the menu redraw scheduler when removing all menu items in response to a refresh. I added some code to change the scheduler to redraw after 700ms rather than the default 100ms after removing a menu and it was a much smoother experience. But, since every machine is different, your mileage may vary.

Therefore it's best to disable the redraw when refreshing and re-enable it after the app has reloaded.

[peterflynn]

I agree with @JeffryBooher -- the problem in this bug is that we do repaint. If we didn't repaint, the UI wouldn't shift upward when the menu bar was removed. That would 'fix' the bug as far as I'm concerned (given that it's probably not feasible to do the super-ideal behavior of resizing the HTML content and then repainting, since the HTML is in the process of being torn down and everything's under heavy load).

[dangoor]

Reviewed low priority to @JeffryBooher