core-ai-bot
commented
3 years ago 
This is because Reload (both with and without Extensions) removes all native menus (so they get reloaded cleanly).
Open core-ai-bot opened 3 years ago
core-ai-bot
commented
3 years ago
This is because Reload (both with and without Extensions) removes all native menus (so they get reloaded cleanly).
core-ai-bot
commented
3 years ago 
@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.
core-ai-bot
commented
3 years ago 
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.
core-ai-bot
commented
3 years ago
@JeffryBooher thanks for testing it. It was worth a try :).
core-ai-bot
commented
3 years ago
@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?
core-ai-bot
commented
3 years ago
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?
core-ai-bot
commented
3 years ago
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.
core-ai-bot
commented
3 years ago
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.
core-ai-bot
commented
3 years ago 
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).
core-ai-bot
commented
3 years ago 
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