Servo: Eliminar el uso de tinyfiledialogs del código de secuencia de comandos

@highfive :

¡Hola @ejmg! Gracias por su interés en trabajar en este problema. ¡Ahora está asignado a ti!

Desasignación por solicitud en IRC.

@highfive :

¡Hola @cdeler! Gracias por su interés en trabajar en este problema. ¡Ahora está asignado a ti!

Hola @jdm ,

Tengo un borrador de implementación a nivel local. ¿Sabes cómo puedo comprobarlo localmente?

@cdeler Puede intentar ejecutar una página que llame a navigator.permissions.request({'name': 'geolocation'}) para verificar que el código modificado se ejecuta correctamente agregando println en los lugares apropiados.

¿Sigues trabajando en este @cdeler?

Estoy interesado en este y ya lo he investigado, pero es posible que necesite alguna guía si es posible.
El primer problema al que me enfrento es cómo puedo usar PermissionStatusBinding::PermissionState en _ports / glutin / browser.rs_

@kleinph Deberá definir una enumeración equivalente en embedder_traits, que está disponible tanto para el script como para ports / glutin, y luego convertir entre las dos enumeraciones según sea necesario.

Bien, intentaré eso @jdm . ¡Gracias!

Un ejemplo de envío de un mensaje desde script / DOM al embedder se encuentra en https://github.com/servo/servo/blob/9d9fff3b0ad843286875051e6544b3d4750d6238/components/script/dom/windowproxy.rs#L264

@highfive :

¡Hola @gatoWololo! Gracias por su interés en trabajar en este problema. ¡Ahora está asignado a ti!

Tengo un sentido general de cómo hacerlo. Una cosa que no me queda clara es cómo enviar el mensaje al incrustador. Tanto # 20428 como # 20429 obtienen un objeto embedder_proxy directamente de la constelación en servo/lib.rs . Sin embargo, al ver cómo se crean las estructuras de Pemisssions, hay bastantes capas antes de llegar finalmente 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 también hay window.send_to_embedder(msg); , por lo que podría enviar un mensaje, pero ¿cómo obtengo una respuesta del incrustador?

Según la conversación aquí: https://github.com/servo/servo/pull/20480 , parece que pasar el embedder_proxy fue la forma acordada?

El mensaje al incrustador puede contener un IpcSender, y el código de permisos puede bloquearse sincrónicamente al recibir la respuesta, o conectar el receptor al enrutador ipc e inyectar un evento en el bucle de eventos del hilo cuando se recibe una respuesta.

En cuanto a cómo comunicarse con el embedder, creo que sería sensato agregar una API send_to_embedder a GlobalScope y almacenar el canal del embedder en GlobalScope. Entonces, el código de permisos debería poder usar algo como self.global().send_to_embedder(...) .

El mensaje al incrustador puede contener un IpcSender

Ah, ya veo.

Suena bien. ¡Trabajaré desde aquí!

Entonces creo que tengo algo funcionando. Pero realmente no puedo probarlo. Pensé que era mi código, pero al usar una versión sin modificar de Servo, sigo recibiendo el error:

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

Donde permissionTest.html es solo una copia de servo/tests/html/permission-test.html .

window.navigator.permissions is undefined

Supongo que es posible que debas habilitarlo

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

Intente ejecutar Servo con --pref dom.permissions.enabled .

Estoy teniendo dificultades para probar mi implementación. La apertura de una página html que llama a los permisos funciona (¡yay!). Pero no puedo ejecutar correctamente las pruebas relacionadas con esta función. Entonces encuentro pruebas que llaman "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) {
...

Luego trato de ejecutar algunas de estas pruebas 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

El primero simplemente falla. ¿El segundo se bloquea pero se espera? Así que no estoy convencido de haber probado nada.

También hay algunas pruebas como tests/html/permission-test.html que no forman parte de wpt. Entonces no estoy seguro de cómo ejecutarlos.

tests / html son pruebas manuales que puede ejecutar con ./mach run tests/html/permission-test.html . Acabo de notar los usos de as_window() en el código de permisos (https://github.com/servo/servo/blob/fd174c54ef4fa6574ae782dacccaeccd14abb936/components/script/dom/permissions.rs#L321-L322) que hará ese código entra en pánico cada vez que se llama en un ámbito que no es de Windows. Necesitamos arreglarlos moviendo la API permission_state_invocation_results a GlobalScope en lugar de a Window.

Gracias por señalar el error en test-background-fetch-allow.html. He presentado # 23645 para solucionarlo.

Gracias. Veo.

lo que hará que ese código entre en pánico cada vez que se llame en un ámbito que no sea de Windows. Necesitamos arreglarlos moviendo la API allow_state_invocation_results a GlobalScope en lugar de a Window.

¿Debería ser un PR separado o parte del mismo?

Sin duda, debería ser un compromiso por separado, pero también podría ser un RP por separado. No esperaría que las pruebas automatizadas fueran buenas para verificar este problema (# 23057), porque el código de permisos suprime la interfaz de usuario cuando se ejecuta sin cabeza.

La solución propuesta en # 23651 estaba en el camino correcto, pero tuve algunos comentarios de revisión que deben abordarse y el autor ha pasado a otras cosas.

@peacerebel ¡ Este podría ser un buen próximo número en el que trabajar!

@PeaceRebel ¡ Este podría ser un buen próximo número en el que trabajar!

Echaremos un vistazo a esto mañana.

@highfive asignarme

¡Hola @PeaceRebel! Gracias por su interés en trabajar en este problema. ¡Ahora está asignado a ti!

Desasignación por inactividad.

Rebasé los cambios en el PR sobre el maestro en mi rama https://github.com/iulianR/servo/tree/issue-23057-tinifiledialogs. Puedo tratar de abordar los comentarios y hacer un nuevo RP si le parece bien.

¡Eso seria genial!

Actualicé mi rama con una confirmación que delega el formato de cadena a los embedders.

Ahora estoy un poco atascado tratando de abordar la segunda parte del PR. No estoy seguro de si necesito un nuevo método en HostTrait , o si debo usar / actualizar el prompt_yes_no() uno que ya existe. Quizás podrías escribirme la firma del método. Gracias.

Creo que usar el método prompt_yes_no suena bien por ahora.