Desktop: Fix frontend message response dispatch (#3247)

* One annoying debugging session later

Discovered that the editor handles frontend messages differently from other messages.
It requires all frontend messages to be fully processed before dispatching any resulting messages.

In the web frontend, this behavior happened implicitly because message dispatch is queued at the current end of the JavaScript execution queue.
For the desktop frontend, I added a vector to collect all responses until the entire batch of frontend messages is handled, and then dispatch them afterwards.

* Fix double click travel

editor/src/messages/portfolio/portfolio_message_handler.rs

@@ -136,10 +136,12 @@ impl MessageHandler<PortfolioMessage, PortfolioMessageContext<'_>> for Portfolio
 
 			// Messages
 			PortfolioMessage::Init => {
-				// Load persistent data from the browser database
-				responses.add(FrontendMessage::TriggerLoadFirstAutoSaveDocument);
+				// Tell frontend to load persistent preferences
 				responses.add(FrontendMessage::TriggerLoadPreferences);
 
+				// Tell frontend to load the current document
+				responses.add(FrontendMessage::TriggerLoadFirstAutoSaveDocument);
+
 				// Display the menu bar at the top of the window
 				responses.add(MenuBarMessage::SendLayout);
 
@@ -149,7 +151,7 @@ impl MessageHandler<PortfolioMessage, PortfolioMessageContext<'_>> for Portfolio
 					node_types: document_node_definitions::collect_node_types(),
 				});
 
-				// Finish loading persistent data from the browser database
+				// Tell frontend to finish loading persistent documents
 				responses.add(FrontendMessage::TriggerLoadRestAutoSaveDocuments);
 			}
 			PortfolioMessage::DocumentPassMessage { document_id, message } => {