Notes - Project Install sync (Jan 15, 2026)

[Dan Murphy]

Notes

• Progress check ins / general updates

• CL - [<install> Element] Always bypass permission

• Mike – is this the correct approach? Discussed with Dan at last sync after you dropped.

• Already merged and respects if permission was denied - [<install> Element] Do not show the permission prompt (7266918) · Gerrit Code Review

• we should think about permission policy - an embedder should be able to control if something is available in a frame.

• right now we make this not available in cross-origin frames, so we don't have to have a policy / permission here.

• we cna think about that later if we need

• my main concern is if we put a prompt in front of users at all for permission

• this design means to me that we don't ned a prompt (pre prompt) for installation workflow

• so no need to touch permission at all for this 'technically'

• the implicit permission here are the limitations on the element - e.g. being in a cross-origin frame

• perhaps in the future there is an enterprise control - and that is more about controlling availability of feature, not about user expressing they want the feature.

• permissions api refers to a 'policy controlled feature' is separate from a 'permission'

• there is a permission policy or document policy that controls the feature within a context

• we also apply enterprise policies in order to determine whether the page's decision for whether a thing should be available is overridden or not

• for geolocation - user might be asked via api to grant permission for geolocation, user might say no

• the element is a way for the user to express, even if they denied before, they want it again - and we ask again.

•  [<install> Element] Do not show the permission prompt (7266918) · Gerrit Code Review LGTM

• CL - [<install> element] Increase maximum install PEPCs allowed per page (7256736) · Gerrit Code Review [done]

• Need review from Mike. Dan on cc

• Mike – is the owner of generate_permission_element_grd.py - Chromium Code Search still OOO?

• Libufzzer failure

• Protobuf full compilation – possibly means includes weren’t updated

• it is failing when executing protoc - compiling protobuf targets. make sure that all files were included correctly for the mojom change?

• CL - [<install> Element] Update string and icon for apps already installed (7302388) · Gerrit Code Review

• Need Googler help with screenshot – install-element-launch.png

• Unclear on execution context/element lifecycle (see Stanley’s comments)

• If no execution context for whatever reason, it’s reasonable to not take an action

• Task queue generally relates order of operations w.r.t everything else on the thread

• Thomas built initial implementation – updating the text in the element needed to be queued because hitting DCHECKs

• Dan – add the PostTask comment to the install_element file

• Mike – cc Thomas

• PWA UX review

• Mike – Is an svg required?

• [<install> Element] Generate launch svg in correct size [473847681] - Chromium

• Mike OK with whatever works

• Followup work – [<install> element] Transform to "Open in Chrome" for <install></install> within a standalone window [475285741] - Chromium

• Dan – what do you want to happen when navigator.install() is called from a standalone window? (or should we ask the UX thread)

• OK with launching new window but no strong opinion (Dan). Use scheduler -> launch command which ties into nav capturing.

• Have everyone else’s concerns been addressed? Or do we need official LGTMs somewhere?

• Mkwst – spec for shared permission element content?

• New stuff

• Started a dev design doc (link to tab) – live

• Started an “install by manifest” doc (link to tab) – not ready for review yet

• Error handling

• Discovered a few small inconsistencies re. error handling, manifest url resolution, and edge case handling with n.i(). Made/making some tweaks as we go.

• Any insights on how to best surface the manifestid for successful installs? In n.i() it’s returned as part of the promise.

• Tacking onto event is fine, or adding as an attribute

• Can overwrite the developer provided id

• Mike OK with most approaches, as long as it’s well spec’d

• Dan – since attribute is optional, seems reasonable to add it to the element as an attribute on successful install. (if the developer already specified one, the returned id should match)

• Fail if it doesn’t match what the dev specified (same as n.i())

• evenet code can always go event.target.getAttribute("manifest-id") (or whatever the name is)

• set the id on the element as an attribute if the developer didn't specify it.

• Mike – it’s normal for attributes to be overwritten. seems reasonable to put as an attribute on the element. seems reasonable to put it on the event.

• Need to know more about developer usage and our goals

• Ex. geolocation exposes the returned geolocation as an attribute on the element

• Element.location would give lat/long coordinates

• Original motivation for manifest-id was Apple using it to uniquely identify the installed app?? – per Dan, this info is out of date

• Telemetry

• Any strong preferences on how we track telemetry during our 2 concurrent OTs?

• Mike – no strong opinion

• Dan – optimize for no post-processing

• 1 for API, 1 for Element, 1 for merged data of both

• WebApp.Install.DoThing.Result

• also add

• WebApp.Install.DoThing.Result.Element

• WebApp.Install.DoThing.Result.Api

• WebApp.Install.{EntryPoint}

• {EntryPoint = element, api}

• Add prefix. 

• Check in on UKMs for element

• Mike – maintain metadata associated with element

• FYI – Edge telemetry dashboard, only 27 clients so far. Roughly 80-85% background installs.

• Confirm new bug priority – [<install> Element] Consider limiting the number of elements pointing to the same application [474262434] - Chromium

• Mike – not needed for OT. suggested it for more flexibility in the future, potentially allow unlimited install elements, but restrict the target application (this would require more refactoring)

• (If time) It seems like our tasks/bugs lately are causing noise for other teams. Did something change with triaging, or should we be tagging them somehow as Microsoft owned?

• please don't worry about it! That's our team process, you are doing the right thing

• status check

• Done: navigator.install API in OT, explainer, spec PR. <install> element (explainer), impl WIP, spec WIP, UX approval.

• Remaining: API OT completion and addressing feedback (e.g. determining the best cross-origin install support, manifest file vs install_url). <install> impl, spec completion, putting in OT. Ship.

• Blockers: Install dialog refresh likely blocking shipping (b/380497638)

• Expected completion: 2026H1

Action items

•