Servo: Remova o uso de tinyfiledialogs do código do script

@highfive : atribua-me

Ei @ejmg! Obrigado pelo seu interesse em trabalhar neste assunto. Agora está atribuído a você!

Cancelamento da atribuição por solicitação no IRC.

@highfive : atribua-me

Ei @cdeler! Obrigado pelo seu interesse em trabalhar neste assunto. Agora está atribuído a você!

Olá @jdm ,

Tenho um projeto de implementação localmente. Você sabe, como posso verificar isso localmente?

@cdeler Você pode tentar executar uma página que chama navigator.permissions.request({'name': 'geolocation'}) para verificar se o código modificado é executado corretamente, adicionando println nos locais apropriados.

Você ainda está trabalhando neste @cdeler?

Estou interessado neste e já investiguei, mas posso precisar de alguma orientação, se for possível.
O primeiro problema que estou enfrentando é como posso usar PermissionStatusBinding::PermissionState em _ports / glutin / browser.rs_

@kleinph Você precisará definir um enum equivalente em embedder_traits, que está disponível para script e ports / glutin, e então converter entre os dois enums conforme necessário.

OK, vou tentar isso @jdm . Obrigado!

Um exemplo de envio de uma mensagem de script / DOM para o incorporador é encontrado em https://github.com/servo/servo/blob/9d9fff3b0ad843286875051e6544b3d4750d6238/components/script/dom/windowproxy.rs#L264

@highfive : atribua-me

Olá @gatoWololo! Obrigado pelo seu interesse em trabalhar neste assunto. Agora está atribuído a você!

Eu tenho uma noção geral de como fazer isso. Uma coisa que não está clara para mim é como enviar a mensagem para o incorporador. Ambos # 20428 e # 20429 obtêm um objeto embedder_proxy diretamente da constelação em servo/lib.rs . No entanto, vendo como as estruturas de Pemissões são criadas, há várias camadas antes de finalmente chegar a create_constellation :

Both of these contain Permissions:
struct WorkerNavigator
struct Navigator

WorkerNavigator is created by WorkerGlobalScope which is created by a:
- ServiceWorkerGlobalScope which is created by a ServiceWorkerManager
   which is init from servo/lib.rs script::init_service_workers(sw_senders);
or
- DedicatedWorkerGlobalScope which is created by run_worker_scope() which is called
  by Worker::Constructor() which does not seem to be called from anywhere...

Navigator is created by Window::Navigator(&self) it is not clear to me how a Window is
created.

Vi que também há window.send_to_embedder(msg); , então poderia enviar uma mensagem, mas como obtenho uma resposta do incorporador?

Com base na conversa aqui: https://github.com/servo/servo/pull/20480 parece que passar o embedder_proxy foi a forma combinada?

A mensagem para o incorporador pode conter um IpcSender, e o código de permissões pode bloquear sincronizadamente ao receber a resposta ou conectar o receptor ao roteador ipc e injetar um evento no loop de eventos do thread quando uma resposta for recebida.

Quanto a como se comunicar com o embedder, acho que seria sensato adicionar uma API send_to_embedder ao GlobalScope e armazenar o canal do embedder no GlobalScope. Então, o código de permissões deve ser capaz de usar algo como self.global().send_to_embedder(...) .

A mensagem para o incorporador pode conter um IpcSender

Ah, entendo.

Soa bem. Vou trabalhar a partir daqui!

Acho que algo está funcionando. Mas não sou realmente capaz de testá-lo. Achei que fosse meu código, mas usando uma versão não modificada do Servo, ainda recebo o erro:

[2019-06-25T21:25:40Z ERROR script::dom::bindings::error] Error at file:///home/gatowololo/permissionTest.html:14:9 window.navigator.permissions is undefined

Onde permissionTest.html é apenas uma cópia de servo/tests/html/permission-test.html .

window.navigator.permissions is undefined

Eu acho que você pode precisar habilitá-lo

https://github.com/servo/servo/blob/e100af57a5bd95701b5310871e9909e3726539f0/resources/prefs.json#L17

Tente executar o Servo com --pref dom.permissions.enabled .

Estou tendo dificuldade em testar minha implementação. Abrir uma página html que chama permissões funciona (yay!). Mas não consigo executar testes relacionados a esse recurso de maneira adequada. Portanto, encontro testes que chamam "navigator.permissions"

> rg "navigator.permissions" *
tests/wpt/web-platform-tests/permissions/interfaces.any.js
24:    self.permissionStatus = await navigator.permissions.query({ name: "geolocation" });
25:    self.permissionStatus = await navigator.permissions.query({ name: "background-fetch" });
37:    Permissions: ['navigator.permissions'],
tests/wpt/web-platform-tests/permissions/test-background-fetch-permission.html
10:    return navigator.permissions.query({name:'background-fetch'}).then(function(result) {
...

Em seguida, tento executar alguns desses testes wpt:

> ./mach test-wpt --pref dom.permissions.enabled --release tests/wpt/web-platform-tests/permissions/interfaces.any.js
...
0:01.87 pid:4508 [2019-06-27T15:49:30Z ERROR servo] expected a Window scope

> ./mach test-wpt --pref dom.permissions.enabled --release tests/wpt/web-platform-tests/permissions/test-background-fetch-permission.html
...
 0:01.65 pid:4793 [2019-06-27T15:51:24Z ERROR servo] assertion failed: !JS_IsExceptionPending(cx)
 0:01.65 pid:4793 Pipeline failed in hard-fail mode.  Crashing!
 0:01.69 TEST_END: CRASH, expected OK

O primeiro simplesmente trava. O segundo trava, mas é o que é esperado? Portanto, não estou convencido de que testei nada.

Existem também alguns testes como tests/html/permission-test.html que não fazem parte do wpt. Portanto, não tenho certeza de como executá-los.

tests / html são testes manuais que você pode executar com ./mach run tests/html/permission-test.html . Acabei de notar o uso de as_window() no código de permissões (https://github.com/servo/servo/blob/fd174c54ef4fa6574ae782dacccaeccd14abb936/components/script/dom/permissions.rs#L321-L322) que fará esse código entra em pânico sempre que é chamado em um escopo não-Window. Precisamos consertá-los movendo a API permission_state_invocation_results para GlobalScope em vez de janela.

Obrigado por apontar a falha em test-background-fetch-permission.html - Solicitei o número 23645 para corrigi-lo.

Obrigado. Entendo.

o que fará com que o código entre em pânico sempre que for chamado em um escopo diferente do Window. Precisamos consertá-los movendo a API permission_state_invocation_results para GlobalScope em vez de Window.

Deve ser um PR separado ou parte do mesmo?

Certamente deveria ser um commit separado, mas também poderia ser um PR separado. Eu não esperaria que os testes automatizados fossem bons para verificar esse problema (# 23057), porque o código de permissões suprime a IU de solicitação ao ser executado sem controle.

A correção proposta em # 23651 estava no caminho certo, mas eu tinha alguns comentários de revisão que precisam ser resolvidos e o autor mudou para outras coisas.

@peacerebel Esta pode ser uma boa próxima edição para trabalhar!

@PeaceRebel Esta pode ser uma boa próxima questão para trabalhar!

Vou dar uma olhada nisso amanhã.

@highfive atribua-me

Olá @PeaceRebel! Obrigado pelo seu interesse em trabalhar neste assunto. Agora está atribuído a você!

Cancelamento da atribuição devido à inatividade.

Reestruturei as mudanças no PR no topo do mestre em meu ramo https://github.com/iulianR/servo/tree/issue-23057-tinifiledialogs. Posso tentar resolver os comentários e fazer um novo PR, se estiver bom para você.

Isso seria bom!

Eu atualizei meu branch com um commit que delega a formatação da string para incorporadores.

Agora estou um pouco preso tentando abordar a segunda parte do PR. Não tenho certeza se preciso de um novo método em HostTrait , ou se devo usar / atualizar o prompt_yes_no() que já existe. Talvez você possa escrever a assinatura do método para mim. Obrigado.

Acho que usar o método prompt_yes_no parece bom por enquanto.