In Nov 2016, canvas team announced that ImageBitmapRenderingContext is shipped and removed the experimental flag in its IDL interface. 14 months later, I accidentally discovered that this rendering context is actually hidden from the users behind --enable-experimental-canvas-features flag, because the code is written inside the
getContext() factory function and it was not very obvious to detect it at the time of release. All the layout tests/pixel tests did not catch this problem because the experimental flags are all automatically turned on for testing.

See https://bugs.chromium.org/p/chromium/issues/detail?id=658734 to understand the full context of the problem.

Note that the RuntimeEnableFeatures::ExperimentalCanvasFeaturesEnabled() function is
frequently inserted into the canvas code, so this problem has a possibility of happening again.

Therefore, after a brief discussion with the rest of the canvas team, I think we might want to improve the layout test infra setup. That is, separating those stable features and experimental features in certain ways, and run the tests with the experimental flags turned on and off respectively.

In addition, certain group of features (e.g.OffscreenCanvas) are now put under the big umbrella of "Experimental Web Platform Features" instead of "Experimental Canvas Features". We want to ensure coherence from the users' point of view when they are interacting with different APIs for OffscreenCanvas (i.e. not finding that one API is only accessible under 1 flag and the other API is only accessible under another flag and these two APIs are frequently used together).

This might requires dig-in and exploration onto what's the possible options. I would assign this task to myself and come back when I'm free; but anyone who's interested and have time to work on it can just take the task from me.


 

In Nov 2016, canvas team announced that ImageBitmapRenderingContext is shipped and removed the experimental flag in its IDL interface. 14 months later, I accidentally discovered that this rendering context is actually hidden from the users behind --enable-experimental-canvas-features flag, because the code is written inside the
getContext() factory function and it was not very obvious to detect it at the time of release. All the layout tests/pixel tests did not catch this problem because the experimental flags are all automatically turned on for testing.

See https://bugs.chromium.org/p/chromium/issues/detail?id=658734 to understand the full context of the problem.

Note that the RuntimeEnableFeatures::ExperimentalCanvasFeaturesEnabled() function is
frequently inserted into the canvas code, so this problem has a possibility of happening again.

Therefore, after a brief discussion with the rest of the canvas team, I think we might want to improve the layout test infra setup. That is, separating those stable features and experimental features in certain ways, and run the tests with the experimental flags turned on and off respectively.

In addition, certain group of features (e.g.OffscreenCanvas) are now put under the big umbrella of "Experimental Web Platform Features" instead of "Experimental Canvas Features". We want to ensure coherence from the users' point of view when they are interacting with different APIs for OffscreenCanvas (i.e. not finding that one API is only accessible under 1 flag and the other API is only accessible under another flag and these two APIs are frequently used together).

This might requires dig-in and exploration onto what's the possible options. I would assign this task to myself and come back when I'm free; but anyone who's interested and have time to work on it can just take the task from me.

-------------------------------------------------------------------------------------------------------

Changed task description:

Based on team discussion, we think it is better that we abandon 'Experimental Canvas Features' flag altogether because it is a confusing umbrella flag for a bundle of different small features, when we already have 'Experimental Web Platform Features' as a universal flag. 

Instead of what's described above, we should identify groups of different features in canvas code, give each of them a unique name, and then put it under "Experimental Web Platform Features" flag.

After that, we then should explore whether we can run the canvas api tests when different small experimental features are turned on, and run shipped API tests without any experimental flags.



 

Changed task description:

Based on team discussion, we think it is better that we abandon 'Experimental Canvas Features' flag altogether because it is a confusing umbrella flag for a bundle of different small features, when we already have 'Experimental Web Platform Features' as a universal flag. 

Instead of what's described above, we should identify groups of different features in canvas code, give each of them a unique name, and then put it under "Experimental Web Platform Features" flag.

After that, we then should explore whether we can run the canvas api tests when different small experimental features are turned on, and run shipped API tests without any experimental flags.


-------------------------------------------------------------------------------------------------------

Background:


In Nov 2016, canvas team announced that ImageBitmapRenderingContext is shipped and removed the experimental flag in its IDL interface. 14 months later, I accidentally discovered that this rendering context is actually hidden from the users behind --enable-experimental-canvas-features flag, because the code is written inside the
getContext() factory function and it was not very obvious to detect it at the time of release. All the layout tests/pixel tests did not catch this problem because the experimental flags are all automatically turned on for testing.

See https://bugs.chromium.org/p/chromium/issues/detail?id=658734 to understand the full context of the problem.

Note that the RuntimeEnableFeatures::ExperimentalCanvasFeaturesEnabled() function is
frequently inserted into the canvas code, so this problem has a possibility of happening again.

Therefore, after a brief discussion with the rest of the canvas team, I think we might want to improve the layout test infra setup. That is, separating those stable features and experimental features in certain ways, and run the tests with the experimental flags turned on and off respectively.

In addition, certain group of features (e.g.OffscreenCanvas) are now put under the big umbrella of "Experimental Web Platform Features" instead of "Experimental Canvas Features". We want to ensure coherence from the users' point of view when they are interacting with different APIs for OffscreenCanvas (i.e. not finding that one API is only accessible under 1 flag and the other API is only accessible under another flag and these two APIs are frequently used together).

This might requires dig-in and exploration onto what's the possible options. I would assign this task to myself and come back when I'm free; but anyone who's interested and have time to work on it can just take the task from me.