| Commit-Queue | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
static WebAppFilter IsAppDeemedToNotBeInRegistry();I feel this naming goes against the general idea that these filters should be for specific capabilities rather than implementation details of the registry. I.e. I'd expect something like IsAppVisibleToUser (or IsAppKnownToUser) (which I guess would both be the reverse of this) to be perhaps a better thing to filter by?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
static WebAppFilter IsAppDeemedToNotBeInRegistry();I feel this naming goes against the general idea that these filters should be for specific capabilities rather than implementation details of the registry. I.e. I'd expect something like IsAppVisibleToUser (or IsAppKnownToUser) (which I guess would both be the reverse of this) to be perhaps a better thing to filter by?
Yeah, naming this function was a pain point for me too, how does `IsAppSurfaceableToUser()` sound? It's closer to `Visible`, and it also feels like it includes the nuances of the registry in it. Wdyt?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
static WebAppFilter IsAppDeemedToNotBeInRegistry();Dibyajyoti PalI feel this naming goes against the general idea that these filters should be for specific capabilities rather than implementation details of the registry. I.e. I'd expect something like IsAppVisibleToUser (or IsAppKnownToUser) (which I guess would both be the reverse of this) to be perhaps a better thing to filter by?
Yeah, naming this function was a pain point for me too, how does `IsAppSurfaceableToUser()` sound? It's closer to `Visible`, and it also feels like it includes the nuances of the registry in it. Wdyt?
This will be the "negation" of it, so `IsAppNotSurfaceableToUser()` is what I went with. PTAL!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
return provider->registrar_unsafe().IsInstallState(This is just a cleanup. Initially I thought the `profile` was a typo and we had to do `provider && ..` since we exit early if profile is nullptr, but we also have a `CHECK(provider)` before this line anyway which will crash, so checking for provider seemed redundant.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
tluk@ PTAL at `c/b/ui/views/site_data`, thanks!
static WebAppFilter IsAppDeemedToNotBeInRegistry();Dibyajyoti PalI feel this naming goes against the general idea that these filters should be for specific capabilities rather than implementation details of the registry. I.e. I'd expect something like IsAppVisibleToUser (or IsAppKnownToUser) (which I guess would both be the reverse of this) to be perhaps a better thing to filter by?
Dibyajyoti PalYeah, naming this function was a pain point for me too, how does `IsAppSurfaceableToUser()` sound? It's closer to `Visible`, and it also feels like it includes the nuances of the registry in it. Wdyt?
This will be the "negation" of it, so `IsAppNotSurfaceableToUser()` is what I went with. PTAL!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[PWA/App Migration] Allow calls to IsInRegistrar to use separate filter
This CL updates the production callsites of IsInRegistrar to instead use
a separate WebAppFilter, whose sole purpose is to identify if an app is
considered "installed" for all purposes. This helps replace all
callsites of IsInRegistrar on production, which eventually makes it
easier to deprecate this call site in favor of GetInstallState(), or
WebAppFilters.
This change also allows all apps suggested from migration to be counted
under that same filter, which ensures that all callsites that are
checking whether this app is not in the registry are migrated to also
include suggested apps in a single swoop.
The only callsite that is not migrated is the WebAppIconManager, where
this is used to overwrite the icons in the app's directory with pending
ones. There is a chance for that use-case to be reused for migration.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |