We need to figure out our story for canvas and color management. Currently we end up color managing images but not CSS. For a canvas used purely for display, the web author probably wants device space. For a canvas where the web author calls getImageData and similar, they probably want sRGB. There are proposed standards related to this, but those are beyond the scope of this bug. Let's just try to be consistent internally and with other browsers, as well as satisfying performance concerns.

For a canvas used purely for display, the web author probably wants device space

What supports this assertion? There are very few cases where device space is actually desirable, the only ones I can think of are meta-apps that let you explore the device gamut. What makes canvas different than CSS and SVG, both of which use sRGB for their RGB colors to ensure device independence?
It doesn't make sense for the same colors to be different between CSS and canvas.
In addition, this is not the venue to decide this. There is already a specification 1 and it says:

In user agents that support CSS, the color space used by a canvas element must match the color space used for processing any colors for that element in CSS.

Other browsers return sRGB in the web dev APIs, but the canvas itself displays in device space. That is what I meant.

I'm not sure what you mean by "displays in". Presumably there are a bunch of inputs to canvas, from fillStyle and strokeStyle to shadowColor, addColorStop, and drawImage, that take inputs that have a known color space (often sRGB, but sometimes something else that could be converted to sRGB). They all need to get converted to device color space eventually (by the time they're drawn) in order to match colors in the rest of the page. The question is when to do that conversion -- it seems like you have either the option of storing the canvas bitmap in sRGB (or some other known color space), or storing it in device color space. Storing it in sRGB seems to have at least three advantages:

• the getImageData and putImageData APIs produce interoperable results across devices (or don't need to do conversion)
• blending operations in canvas produce interoperable results rather than differing slightly as a function of the device color space
• you don't expose color management information as a fingerprinting vector.

Given what you've said about getImageData and putImageData in other browsers, it seems most likely that other browsers store the canvas backing store in sRGB and convert it to device space when drawing, whereas it seems like the initial Gecko implementation was instead storing the canvas backing store in device color space.