Web support tracking issue

[ryanisaacg]

• On-close event listening (Send a LoopDestroyed event when the browser is closed #1155)
• Support fullscreen APIs (Add web fullscreen support #1142)
• Support cursor grab
• Support maximizing a canvas
• Finalize decision on how to handle VideoMode
• Decide if tab title / favicon should be exposed by some cross-platform extension, treated as window icon and title, or neither (They should be left to the user to handle)
• Use raw-window-handle (Add support for raw-window-handle to the web branch #1192)
  • Add web support to raw-window-handle
• Update documentation to reflect web support
• Fix the RedrawRequested implementation on web not conforming to the expected behavior ( Fix web redraw requested #1181)

[hecrj]

Before proceeding, I think we need to get on the same page on how to tackle some of these last features.

On-close event listening

How would this work? We need to keep in mind that right now canvases have a "local" scope. We could attach a beforeunload event listener to the window and proxy the event to all the existing canvases. That would be a global thing, so it may be awkward to implement/maintain, and I feel it could lead to weird bugs overall.

Ideally, we should be able to detect if a particular canvas has been "closed". But when do we consider a canvas to be closed? When it's removed from the DOM? That wouldn't work because a user may want to reinsert the canvas and keep using it.

I am not sure there is a reasonable implementation for this. I am inclined to simply state that a canvas cannot be closed, and ask our users to take care of any unload wiring themselves (the same way we ask them to insert the canvas freely).

Support fullscreen APIs
Support maximizing a canvas

These ones are also tricky. Anything that touches global state (i.e. document, window, etc.) will have erratic/unintuitive behavior when dealing with multiple canvases (unless we emulate a window manager ourselves). What should happen if our users try to maximize/toggle fullscreen on multiple canvases on the same page?

I think I would simply let users handle this too. At least for now. Users will be able to make better informed decisions as they will know exactly how many canvases they will be dealing with.

Decide if tab title / favicon should be exposed by some cross-platform extension, treated as window icon and title, or neither

I think this should be left to the users of the API, as we don't currently have a concept of "main" canvas.

[ryanisaacg]

@hecrj

On-close event listening

How would this work?

I think that closing events are a part of the event loop contract at least, so we could emit a LoopDestroyed event when the browser tab is being closed. I agree that individual canvases should have no concept of being closed.

Support fullscreen APIs
Support maximizing a canvas

Fullscreen support with n canvases should be fine: the browser interface doesn't give us access to monitors anyway, so we can just fullscreen the canvas whenever a window requests it.

I agree that maximization is trickier, and would be very in favor of Not Bothering. Implementing a WM in the browser is not within scope (hopefully).

Decide if tab title / favicon should be exposed by some cross-platform extension, treated as window icon and title, or neither

I'm inclined to say that we should at least try to solve this. If I create exactly one window, then applying that window's title and favicon to the entire tab makes sense. If I create two, it no longer does. I'm not sure it would be possible to special-case, though.

[hecrj]

I think that closing events are a part of the event loop contract at least, so we could emit a LoopDestroyed event when the browser tab is being closed.

Sounds good to me 👍

Fullscreen support with n canvases should be fine: the browser interface doesn't give us access to monitors anyway, so we can just fullscreen the canvas whenever a window requests it.

Is there a canvas API to achieve this? As far as I know, we will need to overlay the canvas on top of everything and fix its size to the window.

If I create exactly one window, then applying that window's title and favicon to the entire tab makes sense.

I don't think this is particularly true. One of the main use cases that I want to be able to satisfy with winit is embedding interactive Rust examples in blog posts. Now, a blog post could only have a single example, but that doesn't mean the example should be allowed to mess with the document's title.

I guess we could create an extension trait that allows marking a window as the "main window", but that kind of API will be allowing multiple windows to be marked as main ones and cause title / favicon fighting. Overall, it can make winit on web less composable.

[ryanisaacg]

Is there a canvas API to achieve this? As far as I know, we will need to overlay the canvas on top of everything and fix its size to the window.

There's a general purpose Fullscreen API that allows fullscreening a single Element and all its children: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API

I don't think this is particularly true. One of the main use cases that I want to be able to satisfy with winit is embedding interactive Rust examples in blog posts. Now, a blog post could only have a single example, but that doesn't mean it should be allowed to mess with the document's title.

That's a very good point, I now agree that winit should keep away from the title and favicon.

[hecrj]

There's a general purpose Fullscreen API that allows fullscreening a single Element and all its children: https://developer.mozilla.org/en-US/docs/Web/API/Fullscreen_API

Oh wow! That is a really neat API I had no clue about! Great news. I agree we should take care of it then!

[ryanisaacg]

It seems like the only web API that we could use to do something like cursor grab (the Pointer Lock API) also inherently hides the mouse cursor by default, and only sort-of allows something like a cursor grab.

Possibly we can add it as a platform-specific extension, but I think that should be after we merge the web version to master.

[ryanisaacg]

There will be a little bit of book-keeping that Winit will have to do for supporting fullscreen properly, which is maintaining the size of the canvas and sending resize events. This shouldn't be too complex so I think it's still a good idea to add support for fullscreen.

[tangmi]

Awesome work! Is this closed by #1221?

[ryanisaacg]

Yup, I've moved the checkbox for web's RedrawRequested API to the tracking issue itself. Since web support has shipped on master, we're good to close this.