Bugzilla

I can reproduce on my Dell XPS 16.

Comparing to my Surface Pro 7+....
- different: my Dell XPS 16 is using Wayland.
- same:  I'm running Ubuntu 24.04.1 LTS, with Mesa graphics driver:
```
WebGL 2 Driver Renderer	Intel -- Mesa Intel(R) Arc(tm) Graphics (MTL)
```

Also, I can reproduce in a debug and opt build on both machines (using STR from comment 14), but unfortunately the bug goes away if  I try to capture in rr (including with chaos mode).  So this is a bit of a heisen-bug that goes away if it's observed too closely.

However, I can still poke in gdb to to see what happens after I've found a bad timestamp. I ran comment 14's STR, and then attached GDB to the content process, and put a breakpoint in `mozilla::dom::CanvasRenderingContext2D::DrawImage`  and then picked `take snapshot` from the video's context menu, and from stepping through, I saw that we're finding the drawable-image-thing using this backtgrace:
```
#0  mozilla::layers::AutoLockImage::GetImage (this=0x7fffc99a40f8, aTimeStamp=...)
    at obj-debug/dist/include/ImageContainer.h:724
#1  0x000070b6312f86a7 in mozilla::dom::HTMLMediaElement::GetCurrentImage (this=0x70b61a309800)
    at dom/html/HTMLMediaElement.cpp:2320
#2  0x000070b634e3e667 in nsLayoutUtils::SurfaceFromElement
    (aElement=0x70b61a309800, aSurfaceFlags=265, aTarget=[(mozilla::gfx::DrawTargetRecording *)] = {...}, aOptimizeSourceSurface=false) at layout/base/nsLayoutUtils.cpp:7279
#3  0x000070b630200704 in mozilla::dom::CanvasRenderingContext2D::DrawImage
```
...and owningImage->mImage (the thing we return and draw to the canvas) is of type `mozilla::layers::GPUVideoImage`.

Given that plus the fact that I'm seeing this on machines with Mesa Graphics so far, I wonder if this is just a graphics driver bug...

I can reproduce on my Dell XPS 16.

Comparing to my Surface Pro 7+....
- different: my Dell XPS 16 is using Wayland.
- same:  I'm running Ubuntu 24.04.1 LTS, with Mesa graphics driver:
```
WebGL 2 Driver Renderer	Intel -- Mesa Intel(R) Arc(tm) Graphics (MTL)
```

Also, I can reproduce in a debug and opt build on both machines (using STR from comment 14), but unfortunately the bug goes away if  I try to capture in rr (including with chaos mode).  So this is a bit of a heisen-bug that goes away if it's observed too closely.

However, I can still poke in gdb to to see what happens after I've found a bad timestamp. I ran comment 14's STR, and then attached GDB to the content process, and put a breakpoint in `mozilla::dom::CanvasRenderingContext2D::DrawImage`  and then picked `take snapshot` from the video's context menu, and from stepping through, I saw that we're finding the drawable-image-thing using this backtgrace:
```
#0  mozilla::layers::AutoLockImage::GetImage (this=0x7fffc99a40f8, aTimeStamp=...)
    at obj-debug/dist/include/ImageContainer.h:724
#1  0x000070b6312f86a7 in mozilla::dom::HTMLMediaElement::GetCurrentImage (this=0x70b61a309800)
    at dom/html/HTMLMediaElement.cpp:2320
#2  0x000070b634e3e667 in nsLayoutUtils::SurfaceFromElement
    (aElement=0x70b61a309800, aSurfaceFlags=265, aTarget=[(mozilla::gfx::DrawTargetRecording *)] = {...}, aOptimizeSourceSurface=false) at layout/base/nsLayoutUtils.cpp:7279
#3  0x000070b630200704 in mozilla::dom::CanvasRenderingContext2D::DrawImage
```
...and owningImage->mImage (the thing we return and draw to the canvas) is of type `mozilla::layers::GPUVideoImage`.

I don't know much about `mozilla::layers::GPUVideoImage` , but given "GPU" in the name, plus the fact that I'm seeing this on machines with Mesa Graphics so far, I wonder if this is just a graphics driver bug...

I can reproduce on my Dell XPS 16 (using STR in comment 14).

Comparing to my Surface Pro 7+....
- different: my Dell XPS 16 is using Wayland.
- same:  I'm running Ubuntu 24.04.1 LTS, with Mesa graphics driver:
```
WebGL 2 Driver Renderer	Intel -- Mesa Intel(R) Arc(tm) Graphics (MTL)
```

Also, I can reproduce in a debug and opt build on both machines (using STR from comment 14), but unfortunately the bug goes away if  I try to capture in rr (including with chaos mode).  So this is a bit of a heisen-bug that goes away if it's observed too closely.

However, I can still poke in gdb to to see what happens after I've found a bad timestamp. I ran comment 14's STR, and then attached GDB to the content process, and put a breakpoint in `mozilla::dom::CanvasRenderingContext2D::DrawImage`  and then picked `take snapshot` from the video's context menu, and from stepping through, I saw that we're finding the drawable-image-thing using this backtgrace:
```
#0  mozilla::layers::AutoLockImage::GetImage (this=0x7fffc99a40f8, aTimeStamp=...)
    at obj-debug/dist/include/ImageContainer.h:724
#1  0x000070b6312f86a7 in mozilla::dom::HTMLMediaElement::GetCurrentImage (this=0x70b61a309800)
    at dom/html/HTMLMediaElement.cpp:2320
#2  0x000070b634e3e667 in nsLayoutUtils::SurfaceFromElement
    (aElement=0x70b61a309800, aSurfaceFlags=265, aTarget=[(mozilla::gfx::DrawTargetRecording *)] = {...}, aOptimizeSourceSurface=false) at layout/base/nsLayoutUtils.cpp:7279
#3  0x000070b630200704 in mozilla::dom::CanvasRenderingContext2D::DrawImage
```
...and owningImage->mImage (the thing we return and draw to the canvas) is of type `mozilla::layers::GPUVideoImage`.

I don't know much about `mozilla::layers::GPUVideoImage` , but given "GPU" in the name, plus the fact that I'm seeing this on machines with Mesa Graphics so far, I wonder if this is just a graphics driver bug...

I can reproduce on my Dell XPS 16 (using STR in comment 14).

Comparing to my Surface Pro 7+....
- different: my Dell XPS 16 is using Wayland.
- same:  I'm running Ubuntu 24.04.1 LTS, with Mesa graphics driver:
```
WebGL 2 Driver Renderer	Intel -- Mesa Intel(R) Arc(tm) Graphics (MTL)
```

Also, I can reproduce in a debug and opt build on both machines (using STR from comment 14), but unfortunately the bug goes away if  I try to capture in rr (including with chaos mode).  So this is a bit of a heisen-bug that goes away if it's observed too closely.  Not sure if that's due to timing vs. something else that works out differently when running under rr.

However, I can still poke in gdb to to see what happens after I've found a bad timestamp. I ran comment 14's STR, and then attached GDB to the content process, and put a breakpoint in `mozilla::dom::CanvasRenderingContext2D::DrawImage`  and then picked `take snapshot` from the video's context menu, and from stepping through, I saw that we're finding the drawable-image-thing using this backtgrace:
```
#0  mozilla::layers::AutoLockImage::GetImage (this=0x7fffc99a40f8, aTimeStamp=...)
    at obj-debug/dist/include/ImageContainer.h:724
#1  0x000070b6312f86a7 in mozilla::dom::HTMLMediaElement::GetCurrentImage (this=0x70b61a309800)
    at dom/html/HTMLMediaElement.cpp:2320
#2  0x000070b634e3e667 in nsLayoutUtils::SurfaceFromElement
    (aElement=0x70b61a309800, aSurfaceFlags=265, aTarget=[(mozilla::gfx::DrawTargetRecording *)] = {...}, aOptimizeSourceSurface=false) at layout/base/nsLayoutUtils.cpp:7279
#3  0x000070b630200704 in mozilla::dom::CanvasRenderingContext2D::DrawImage
```
...and owningImage->mImage (the thing we return and draw to the canvas) is of type `mozilla::layers::GPUVideoImage`.

I don't know much about `mozilla::layers::GPUVideoImage` , but given "GPU" in the name, plus the fact that I'm seeing this on machines with Mesa Graphics so far, I wonder if this is just a graphics driver bug...