Putting a subset of constructors behind a runtime enabled flag in IDL file |
|||||||
Issue descriptionWhen adding new features to Chrome, sometimes it is needed to add new constructors to the IDL file but keep them behind a flag to not expose the experimental features. Currently, it seems that IDL does not allow this. A use case is as follows: - For ImageData, we have [Constructor(unsigned long sw, unsigned long sh),] - We want to add [Constructor(unsigned long sw, unsigned long sh, ImageDataColorSpace colorSpace),] - We want the new constructor to be behind ExperimentalCanvasFeatures runtime enabled flag. This is not a blocking bug, but the current solution we have found is to replace the new XXX constructors with createXXX methods. This forces us to come back to the code and layout tests and fix all the function calls before removing the experimental flag and shipping the feature.
,
Apr 11 2017
,
Jun 1 2017
Looks similar to https://groups.google.com/a/chromium.org/forum/?utm_medium=email&utm_source=footer#!msg/blink-dev/WkNcwh6aISA/3SeSuSICBwAJ Probably we can use [Expose=(Window ExperimentalCanvasFeatures)] ? Assigning to peria@ as he is looking at this kind of issue.
,
Nov 20 2017
,
May 3 2018
,
May 25 2018
,
Jul 25
,
Nov 2
Note for myself;
One idea for this issue is to introduce a new Blink specific extended attribute [Construct] that is applicable to operations, and define such non-standard constructors on Global interfaces.
For example, for the case of #0,
// we have no changes in image_data.idl
[
Constructor(unsigned long sw, unsigned long sh),
Exposed=(Window, Worker)
] ImageData { ... };
partial interface mixin WindowOrWorker {
[Construct, RuntimeEanbled=ExperimentalCanvasFeatures] ImageData(unsigned long sw, unsigned long sh, ImageDataColorSpace colorSpace);
};
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 Deleted