webmanifest support

[ThaUnknown]

trafficstars

Supporting webmanifest could be cool, this would allow for stuff like custom titlebar colors, icons, shortcuts etc, I can see 2 ways of implementing this:

1. suffer and implement each feature by hand
2. register the site as an app: going to the options burger, more tools, create shortcut and setting it as a window creates the site as a ""standalone app"" which registers an app ID, then the browser simply launches it with --app-id ex: chrome_proxy.exe --profile-directory=Default --app-id=cinhimbnkkaeohfgghhklpknlkffjgod, this would automatically support all webmanifest features, even ones enabled experimentally with flags and fix stuff like #12

[CanadaHonk]

Have you checked if this already works? Unsure if launching a site with --app would use it or if it's installed only.

[ThaUnknown]

@CanadaHonk yes this works, but it's INSANELY specific [assumption] the app-id is a hash of: site URL, profile name and profile location this worked when I did this for startBrowser:

export default async ({ browserName, browserPath, dataPath }, { url, windowSize }) => {
  return await StartBrowser(browserPath, [
    `--app-id=mjoklplbddabcmpepnokjaffbmgbkkgg`,
    `--remote-debugging-pipe`,
    windowSize ? `--window-size=${windowSize.join(',')}` : '',
    ...`--new-window --disable-extensions --disable-default-apps --disable-breakpad --disable-crashpad --disable-background-networking --disable-domain-reliability --disable-component-update --disable-sync --disable-features=AutofillServerCommunication ${presets.perf}`.split(' ')
  ], 'stdio', { browserName });
};

I had to remove --profile-directory=Default and the dataPath option for it to work. End result: Respecting webmanifest it has a custom title bar color and the chrome controls, sick! Here's what I did [brave] For github: make sure to check Open as window went to desktop and got app id from the launch parameters of the nearly created shortcut "C:\Program Files\BraveSoftware\Brave-Browser\Application\chrome_proxy.exe" --profile-directory=Default --app-id=mjoklplbddabcmpepnokjaffbmgbkkgg this doesn't actually have to be chrome_proxy, it can just be chrome.exe [brave.exe in this case]

So I assume for this work gluton would need so somehow create an app like the shortcut thing did, and launch it from the same path and profile that created the app, no clue exactly how to do this

this is great as it decreases the workload of managing these features by a mile, especially stuff like custom title bars across different operating systems which frameworks like tauri struggle with a LOT and potentially allows us to re-use features like launch on startup which chromium has already implemented

F firefox support ;P

[CanadaHonk]

I meant already possible i.e. --app already handles webmanifest/PWA features without requiring an --app-id or install haha, but good info nevertheless.

[ThaUnknown]

I meant already possible i.e. --app already handles webmanifest/PWA features without requiring an --app-id or install haha, but good info nevertheless.

yes but app-id install enables PWA features, --app doesn't, it only does some webmanifest things, but not all

[ThaUnknown]

notable issue: installable PWAs sometimes get unregistered across updates so the app-id would likely need to be re-registered after each startup

this also doesn't solve the issue of API's such as FileHandlingAPI and WebShareTargetAPI, as either: A the file handle won't be forwarded to the browser via the launchQueue or the node wrapper won't launch alongside the app, hmmm

[ThaUnknown]

documenting: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/windows_pwa_integration.md#file-handling-support

[CanadaHonk]

Closing as Firefox has no support, so would introduce major compatibility issues. Possible to revisit in future if/when isolated web apps become more of a standard.