Sequência da #209. O modo portátil está coberto no Windows e no Linux; o macOS continua descoberto, e vale registrar em vez de deixar implícito.
O que está resolvido
O <app>/data recebe tudo que o app controla diretamente em qualquer plataforma. O que faltava era o WebView, e ele foi resolvido assim:
- Windows:
WEBVIEW2_USER_DATA_FOLDER era código morto (o Tauri resolvia o diretório antes de a variável ser lida), então a janela passou a ser construída no setup() com .data_directory() explícito.
- Linux: o mesmo
.data_directory() alimenta base_data_directory, base_cache_directory e os cookies do WebKitGTK.
Ambos verificados pelo job smoke da CI, que reprova se qualquer coisa aparecer no perfil do usuário.
O que falta
O wry não lê data_directory no WKWebView:
$ grep -rn "data_directory" wry-0.54.2/src/wkwebview/*.rs
(nenhum resultado)
Contra wry-0.54.2/src/webkitgtk/web_context.rs, que usa em três lugares. Ou seja: no macOS não existe, hoje, o caminho que a correção usou nas outras duas plataformas. Passar .data_directory() lá seria no-op — pior que não fazer nada, porque daria a impressão de estar coberto.
Por isso o cfg ficou em any(windows, target_os = "linux") explicitamente, em vez de valer para todos.
Impacto real
Menor que nas outras plataformas, mas não nulo: no macOS o WKWebView guarda dados no container do app dentro de ~/Library, então um usuário rodando o OmniGet de um pendrive ainda deixa rastro na máquina. Não é vazamento de credencial — é o modo portátil não cumprindo o que promete.
Caminhos possíveis
WKWebsiteDataStore com diretório customizado exige API não exposta pelo wry — provavelmente issue upstream.- Detectar e avisar: se
portable.txt estiver presente no macOS, dizer ao usuário que o webview não é portátil nessa plataforma. Honesto, e barato.
A opção 2 é implementável hoje e não depende de ninguém. Deixo em aberto porque é decisão de produto, não de código.
Como confirmar quando alguém mexer
scripts/smoke-test.mjs --portable já checa ~/Library/Application Support/wtf.tonho.omniget. Basta adicionar macos-latest à matriz do job smoke — o teste que reprovaria já existe.
Sequência da #209. O modo portátil está coberto no Windows e no Linux; o macOS continua descoberto, e vale registrar em vez de deixar implícito.
O que está resolvido
O
<app>/datarecebe tudo que o app controla diretamente em qualquer plataforma. O que faltava era o WebView, e ele foi resolvido assim:WEBVIEW2_USER_DATA_FOLDERera código morto (o Tauri resolvia o diretório antes de a variável ser lida), então a janela passou a ser construída nosetup()com.data_directory()explícito..data_directory()alimentabase_data_directory,base_cache_directorye os cookies do WebKitGTK.Ambos verificados pelo job
smokeda CI, que reprova se qualquer coisa aparecer no perfil do usuário.O que falta
O
wrynão lêdata_directoryno WKWebView:Contra
wry-0.54.2/src/webkitgtk/web_context.rs, que usa em três lugares. Ou seja: no macOS não existe, hoje, o caminho que a correção usou nas outras duas plataformas. Passar.data_directory()lá seria no-op — pior que não fazer nada, porque daria a impressão de estar coberto.Por isso o
cfgficou emany(windows, target_os = "linux")explicitamente, em vez de valer para todos.Impacto real
Menor que nas outras plataformas, mas não nulo: no macOS o WKWebView guarda dados no container do app dentro de
~/Library, então um usuário rodando o OmniGet de um pendrive ainda deixa rastro na máquina. Não é vazamento de credencial — é o modo portátil não cumprindo o que promete.Caminhos possíveis
WKWebsiteDataStorecom diretório customizado exige API não exposta pelowry— provavelmente issue upstream.portable.txtestiver presente no macOS, dizer ao usuário que o webview não é portátil nessa plataforma. Honesto, e barato.A opção 2 é implementável hoje e não depende de ninguém. Deixo em aberto porque é decisão de produto, não de código.
Como confirmar quando alguém mexer
scripts/smoke-test.mjs --portablejá checa~/Library/Application Support/wtf.tonho.omniget. Basta adicionarmacos-latestà matriz do jobsmoke— o teste que reprovaria já existe.