iwa: Introduce the chromeos.iwa interface for blink extensions [chromium/src : main]
Edman Anjos (Gerrit)
Edman Anjos added 1 comment![]( "Open in Gerrit")
Related details
- Andrew Rayskiy
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andrew Rayskiy (Gerrit)
Andrew Rayskiy added 3 comments![]( "Open in Gerrit")
# Copyright 2026 The Chromium AuthorsShouldn't we rather keep all of this in `/chromeos/cros_apps/`?
auto result = content::EvalJs(frame, "window.chromeos.iwa.echo('hello')");Testing that `chromeos.iwa` is defined should already be enough!
DOMString echo(DOMString message);We don't randomly release functions in blink! Let's remove this.
As for the interface itself, it would be good to hide it behind a `runtime_enabled_flag` until we have at least one proper function to it (not here, but at the member level in `cros.idl`)
Related details
- Edman Anjos
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Edman Anjos (Gerrit)
Edman Anjos added 3 comments![]( "Open in Gerrit")
# Copyright 2026 The Chromium AuthorsShouldn't we rather keep all of this in `/chromeos/cros_apps/`?
no, I don't think we want to launch that code, or build up on it
auto result = content::EvalJs(frame, "window.chromeos.iwa.echo('hello')");Testing that `chromeos.iwa` is defined should already be enough!
Acknowledged, I know, but this seems acceptable too?
DOMString echo(DOMString message);We don't randomly release functions in blink! Let's remove this.
As for the interface itself, it would be good to hide it behind a `runtime_enabled_flag` until we have at least one proper function to it (not here, but at the member level in `cros.idl`)
the whole chromeos interface is already behind a flag. I intend to introduce a runtime flag for APIs that are not a placeholder.
the placeholder will help place the boilerplate scaffold that setShape can come into soon.
Related details
- Andrew Rayskiy
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andrew Rayskiy (Gerrit)
Andrew Rayskiy added 1 comment![]( "Open in Gerrit")
DOMString echo(DOMString message);Edman AnjosWe don't randomly release functions in blink! Let's remove this.
As for the interface itself, it would be good to hide it behind a `runtime_enabled_flag` until we have at least one proper function to it (not here, but at the member level in `cros.idl`)
the whole chromeos interface is already behind a flag. I intend to introduce a runtime flag for APIs that are not a placeholder.
the placeholder will help place the boilerplate scaffold that setShape can come into soon.
It's fine to create the interface, but what's the point of the function per se? 😊 It doesn't help you set anything up, it doesn't help you with tests; having an empty interface is perfectly acceptable already.
Related details
- Edman Anjos
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Simon Hangl (Gerrit)
Simon Hangl added 1 comment![]( "Open in Gerrit")
This directory is the browser counterpart to the Blink extensions defined indriveby comment: i am not sure we want to put that stuff in ash (at least it doesn't match my mental model of what ash is for)
Edman Anjos (Gerrit)
Edman Anjos added 2 comments![]( "Open in Gerrit")
This directory is the browser counterpart to the Blink extensions defined indriveby comment: i am not sure we want to put that stuff in ash (at least it doesn't match my mental model of what ash is for)
Can you clarify where you would put it instead?
DOMString echo(DOMString message);Edman AnjosWe don't randomly release functions in blink! Let's remove this.
As for the interface itself, it would be good to hide it behind a `runtime_enabled_flag` until we have at least one proper function to it (not here, but at the member level in `cros.idl`)
Andrew Rayskiythe whole chromeos interface is already behind a flag. I intend to introduce a runtime flag for APIs that are not a placeholder.
the placeholder will help place the boilerplate scaffold that setShape can come into soon.
It's fine to create the interface, but what's the point of the function per se? 😊 It doesn't help you set anything up, it doesn't help you with tests; having an empty interface is perfectly acceptable already.
It helps to scaffold the interface here and the mojo connection in another CL. when these things are in place adding setShape should be simpler with the changes needed for that API, not the surrounding boilerplate.
Related details
- Andrew Rayskiy
- Simon Hangl
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Edman Anjos (Gerrit)
Edman Anjos added 2 comments![]( "Open in Gerrit")
This directory is the browser counterpart to the Blink extensions defined inEdman Anjosdriveby comment: i am not sure we want to put that stuff in ash (at least it doesn't match my mental model of what ash is for)
Can you clarify where you would put it instead?
- Andrew Rayskiy
- Georg Neis
- Simon Hangl
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andrew Rayskiy (Gerrit)
Andrew Rayskiy added 1 comment![]( "Open in Gerrit")
@ne...@chromium.org, we're basically reusing the same `cros` namespace in blink extensions with a different browser-side backend (`/chromeos/isolated_web_app/` instead of `/chromeos/cros_apps/`). Given that the latter only defines an empty `cros.kiosk` namespace, won't it make more sense for us to take over that directory instead for our `cros.iwa` stuff? Or completely delete everything in `/chromeos/cros_apps/` and move the only meaningful piece -- tab helper with a pre-commit logic to enable features -- to `/chromeos/isolated_web_apps/`?
Related details
- Georg Neis
- Simon Hangl
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Edman Anjos (Gerrit)
Edman Anjos added 1 comment![]( "Open in Gerrit")
@ne...@chromium.org, we're basically reusing the same `cros` namespace in blink extensions with a different browser-side backend (`/chromeos/isolated_web_app/` instead of `/chromeos/cros_apps/`). Given that the latter only defines an empty `cros.kiosk` namespace, won't it make more sense for us to take over that directory instead for our `cros.iwa` stuff? Or completely delete everything in `/chromeos/cros_apps/` and move the only meaningful piece -- tab helper with a pre-commit logic to enable features -- to `/chromeos/isolated_web_apps/`?
There might be some misunderstanding in this comment.
`//c/b/chromeos/cros_apps` declares the rules to enable some APIs, and enables them at runtime, but it doesn't include the API implementation (e.g. mojo services and any logic).
`//c/b/chromeos/isolated_web_app` is the implementation directory. Whether we'd use `cros_apps` to enable runtime flags is a different matter, not really relevant for this particular CL.
Related details
- Andrew Rayskiy
- Georg Neis
- Simon Hangl
Edman Anjos (Gerrit)
Edman Anjos added 1 comment![]( "Open in Gerrit")
- Andrew Rayskiy
- Georg Neis
- Hidehiko Abe
- Simon Hangl
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |