Bugzilla

This is happening because a canvas lazily-creates its context, and [HTMLCanvasElement::GetFrameCaptureState](https://searchfox.org/mozilla-central/rev/1d43d9f3d0ffcbdb619cfd1e2911fb22d1456657/dom/html/HTMLCanvasElement.cpp#1212) has no capture state when there is no context. In this testcase, `HTMLCanvasElement::Register` is called when there is no context, and then `Unregister` is called when it does. The assertion happens because we're unwatching some state that was never watched.

Possible fixes:
1) Eagerly create context. This is expensive and too big a change.
2) Create the state watch when the context is created. This requires the `HTMLCanvasElement` to be notified when the context is created. Maybe tricky.
3) Independently track whether or not we are watching state and only unwatch it if we watched it in the first place. This would work but it would allow `HTMLCanvasElement` to be in a state where it wasn't watching its owning element's capture state at all. That's would probably just hide other more serious problems.

I'll try to build a solution around idea 2, above.

This is happening because a canvas lazily-creates its context, and [HTMLCanvasElement::GetFrameCaptureState](https://searchfox.org/mozilla-central/rev/1d43d9f3d0ffcbdb619cfd1e2911fb22d1456657/dom/html/HTMLCanvasElement.cpp#1212) has no capture state when there is no context. In this testcase, `RequestedFrameRefreshObserver::Register` is called when there is no context, and then `Unregister` is called when it does. The assertion happens because we're unwatching some state that was never watched.

Possible fixes:
1) Eagerly create context. This is expensive and too big a change.
2) Create the state watch when the context is created. This requires the `HTMLCanvasElement` to be notified when the context is created. Maybe tricky.
3) Independently track whether or not we are watching state and only unwatch it if we watched it in the first place. This would work but it would allow `HTMLCanvasElement` to be in a state where it wasn't watching its owning element's capture state at all. That's would probably just hide other more serious problems.

I'll try to build a solution around idea 2, above.