Bug 1798014 Comment 68 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore receive all input events
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

(Z-order goes from top-to-bottom)

MozillaWindowClass (UI Process)
|
| -> NewWindowClass (UI Process)
| -> MozillaCompositorWindowClass (GPU Process)
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

MozillaWindowClass (UI Process)
|
| -> NewWindowClass (UI Process)
| -> MozillaCompositorWindowClass (GPU Process)
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

MozillaWindowClass (UI Process)
│
├ -> NewWindowClass (UI Process)
├ -> MozillaCompositorWindowClass (GPU Process)
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

```
MozillaWindowClass (UI Process)
│
├ -> NewWindowClass (UI Process)
├ -> MozillaCompositorWindowClass (GPU Process)

```
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

```
MozillaWindowClass (UI Process)
│
├ -> NewWindowClass (UI Process)
├ -> MozillaCompositorWindowClass (GPU Process)
```
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

```
MozillaWindowClass (UI Process)
│
├-> NewWindowClass (UI Process)
├-> MozillaCompositorWindowClass (GPU Process)
```
Even though this "Chrome Legacy Window" thing I noticed above was a dead end, it actually did give me an idea of how we might solve this: Perhaps it would work to create another child window of the main process `nsWindow` that is also in the main process and would be a sibling of the GPU compositor window, but sits above it in the Z-order, and is composed of entirely "transparent black"  (RGBA{0, 0, 0, 0}) pixels.

This window would therefore be entirely invisible, so the user would see the GPU process compositor window, but it would receive all input events and be able to pass it on to parent (see diagram below)

Of course... This doesn't answer the question about why Chrome is able to make this work without this window. Ultimately that question still needs to be answered, but doing this might actually be a good idea regardless of the outcome of my investigation.

Diagram of what the window hierarchy would look like with this idea:

(Z-order goes from top-to-bottom)

```
MozillaWindowClass (UI Process)
│
├-> NewWindowClass (UI Process)
└-> MozillaCompositorWindowClass (GPU Process)
```

Back to Bug 1798014 Comment 68