Welcome screen

[mfish33]

Closes #405

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	cf3dae6
Status:	✅  Deploy successful!
Preview URL:	https://dc5adde4.graphite-master.pages.dev
Branch Preview URL:	https://welcome-screen.graphite-master.pages.dev

View logs

[Keavon]

Bug I just found:

1. Refresh the page to the welcome screen (no existing documents)
2. Open the New Document dialog
3. Uncheck Infinite Canvas and click OK to make the new document

The white rectangle for the canvas is stuck in the top left corner (if the default 1920x1080 would already fill the viewport at 100% scale at your monitor resolution and window size, refresh the page and this time set the document dimensions to something smaller).

The JS console displays this:

The canvas can't be panned when it is frozen. Also, the displayed scale 0%, although entering a new value is possible and doing so unfreezes panning.

This doesn't happen for infinite canvas. It doesn't happen for any documents created after the first document is created upon loading the app (even if the first document is infinite canvas, even if the first document is closed to show the welcome screen again).

I don't have time to debug this today, but I wonder if you have any ideas @0HyperCube?

[0HyperCube]

@Keavon This is due to the zoom document to fit having the viewport bounds as (0,0) and so doing a division by 0. The viewport bounds are requested to be updated but the dispatcher keeps the frontend message in a queue and handles the whole backend stack first. I added an exception in this case, so we immediately deal with the frontend message. I also simplified the new document dialog code to remove unnecessary messages (which were previously needed due to the message ordering).

[Keavon]

@Keavon This is due to the zoom document to fit having the viewport bounds as (0,0) and so doing a division by 0. The viewport bounds are requested to be updated but the dispatcher keeps the frontend message in a queue and handles the whole backend stack first. I added an exception in this case, so we immediately deal with the frontend message. I also simplified the new document dialog code to remove unnecessary messages (which were previously needed due to the message ordering).

Excellent sleuthing, quite an interesting reminder about the challenges we'll continue to face with message ordering where vigilance and testing will be required. I'm glad you also noticed that you could clean up the code now so that didn't become an unneeded relic, thank you for keeping the code lean and clean!