Contact emails
[email protected]

Specification
https://wicg.github.io/manifest-incubations/index.html#execute-a-file-handler-launch


Summary
Prevent the launchQueue from re-sending the last LaunchParams (including file 
handles) when a user reloads the page. Currently, a page refresh triggers the 
launch consumer again with the data from the original launch. This change 
ensures that a reload is treated as a standard navigation rather than a 
"re-launch," and the launchQueue will not be populated with duplicate files 
unless a new file launch event occurs. The re-queueing was never spec'd, and 
was an unfortunate never-removed stop-gap that was implemented before file 
handles could be saved to IndexedDB.


Blink component
UI>Browser>WebAppInstalls>FileHandling


Web Feature ID
app-file-handlers


Risks




Interoperability and Compatibility
Interoperability risk: Low. This aligns with the consensus that reloads should 
not be treated as new file launches. Compatibility risk: Low. Theoretically 
some PWAs may exist that rely on this behavior to "recover" file handles after 
a crash or a manual refresh, and these applications will now need to use 
persistent storage (like IndexedDB) to track active file handles across 
sessions. However, given the low usage, it seems unlikely this is the case: 
https://chromestatus.com/metrics/feature/timeline/popularity/3875

Gecko: No signal

WebKit: No signal

Web developers: Strongly positive 
(https://github.com/WICG/web-app-launch/issues/92)

Other signals:


Ergonomics
This significantly improves ergonomics by removing the need for "deduplication" 
or "reload-detection" boilerplate in the launch consumer.


Activation
None, this makes the feature behave in a more predictable manner.


Security
This change is privacy-neutral or slightly positive, as it ensures that file 
handles are not unnecessarily re-exposed to the application script purely via a 
page refresh.


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it 
has potentially high risk for Android WebView-based applications?
No information provided



Debuggability
Developers can test this by opening a file in their PWA, then hitting the 
browser's reload button. The launchQueue consumer should not fire a second time.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, 
ChromeOS, Android, and Android WebView)?
No
LaunchQueue / Web App Launch, and File Handling is not yet supported on Android.


Is this feature fully tested by web-platform-tests?
No
Unfortunately there are no web platform tests for file handling.




Tracking bug
https://crbug.com/40204185


Measurement
Adoption can be measured via the file handling launch feature counter: 
https://chromestatus.com/metrics/feature/timeline/popularity/3875


Estimated milestones


Shipping on desktop 146

DevTrial on desktop 146




Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5986946868445184


This intent message was generated by Chrome Platform Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69869164.050a0220.29f6fd.01be.GAE%40google.com.

Reply via email to