Servo: Supprimer l'utilisation de tinyfiledialogs du code de script

Créé le 19 mars 2019  ·  36Commentaires  ·  Source: servo/servo

Ceci est très similaire à https://github.com/servo/servo/issues/20428 et https://github.com/servo/servo/issues/20429. À l'heure actuelle, le code d'autorisation DOM appelle directement la bibliothèque tinyfiledialogs pour créer une interface utilisateur d'autorisation. Au lieu de cela, nous devrions envoyer un message à l'intégrateur et faire en sorte que la couche d'intégration crée l'interface utilisateur.

Code : components/script/dom/permissions.rs , components/embedder_traits/lib.rs , ports/servo/browser.rs , ports/libsimpleservo/api/src/lib.rs

A-contenscript A-embedding C-assigned E-less easy

Commentaire le plus utile

Essayez d'exécuter Servo avec --pref dom.permissions.enabled .

Tous les 36 commentaires

@highfive : assignez-moi

Salut @ejmg ! Merci de l'intérêt que vous portez à travailler sur ce problème. Il vous est désormais attribué !

Désassignation par requête sur IRC.

@highfive : assignez-moi

Salut @cdeler ! Merci de l'intérêt que vous portez à travailler sur ce problème. Il vous est désormais attribué !

Bonjour @jdm ,

J'ai un projet de mise en œuvre localement. Savez-vous, comment puis-je le vérifier localement?

@cdeler Vous pouvez essayer d'exécuter une page qui appelle navigator.permissions.request({'name': 'geolocation'}) pour vérifier que le code modifié s'exécute correctement en ajoutant println aux endroits appropriés.

Travaillez-vous toujours sur ce @cdeler ?

Je suis intéressé par celui-ci et je l'ai déjà examiné, mais j'ai peut-être besoin de conseils si cela est possible.
Le premier problème auquel je suis confronté est de savoir comment utiliser PermissionStatusBinding::PermissionState dans _ports/glutin/browser.rs_

@kleinph Vous devrez définir une énumération équivalente dans embedder_traits, qui est disponible à la fois pour le script et les ports/glutin, puis convertir entre les deux énumérations si nécessaire.

OK, je vais essayer ça @jdm . Merci!

Un exemple d'envoi d'un message de script/DOM à l'intégrateur se trouve sur https://github.com/servo/servo/blob/9d9fff3b0ad843286875051e6544b3d4750d6238/components/script/dom/windowproxy.rs#L264

@highfive : assignez-moi

Salut @gatoWololo ! Merci de l'intérêt que vous portez à travailler sur ce problème. Il vous est désormais attribué !

J'ai une idée générale de la façon de le faire. Une chose qui n'est pas claire pour moi est de savoir comment envoyer le message à l'intégrateur. #20428 et #20429 obtiennent tous deux un objet embedder_proxy directement de la constellation dans servo/lib.rs . Cependant, en voyant comment les structures Pemisssions sont créées, il y a pas mal de couches avant d'enfin arriver à 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.

J'ai vu qu'il y avait aussi window.send_to_embedder(msg); , donc je pourrais envoyer un message, mais comment puis-je obtenir une réponse de l'intégrateur ?

Sur la base de la conversation ici : https://github.com/servo/servo/pull/20480, il semble que passer le embedder_proxy était la voie convenue ?

Le message à l'embedder peut contenir un IpcSender, et le code d'autorisation peut soit bloquer de manière synchrone lors de la réception de la réponse, soit connecter le récepteur au routeur ipc et injecter un événement dans la boucle d'événement du thread lorsqu'une réponse est reçue.

Quant à la façon de communiquer avec l'embedder, je pense qu'il serait judicieux d'ajouter une API send_to_embedder à GlobalScope et de stocker le canal d'embedder dans GlobalScope. Ensuite, le code d'autorisation devrait pouvoir utiliser quelque chose comme self.global().send_to_embedder(...) .

Le message à l'embedder peut contenir un IpcSender

Ah, je vois.

Ça a l'air bien. Je vais travailler d'ici !

Donc je pense que j'ai quelque chose qui marche. Mais je ne suis pas vraiment en mesure de le tester. Je pensais que c'était mon code, mais en utilisant une version non modifiée de Servo, j'obtiens toujours l'erreur :

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

permissionTest.html n'est qu'une copie de servo/tests/html/permission-test.html .

window.navigator.permissions is undefined

Je suppose que vous devrez peut-être l'activer

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

Essayez d'exécuter Servo avec --pref dom.permissions.enabled .

J'ai du mal à tester mon implémentation. L'ouverture d'une page html qui appelle les autorisations fonctionne (yay!). Mais je ne parviens pas à exécuter correctement les tests liés à cette fonctionnalité. Je trouve donc des tests qui appellent "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) {
...

J'essaie ensuite d'exécuter certains de ces tests 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

Le premier plante. Le second plante mais c'est prévu ? Je ne suis donc pas convaincu d'avoir testé quoi que ce soit.

Il existe également des tests comme tests/html/permission-test.html qui ne font pas partie de wpt. Je ne sais donc pas comment les exécuter.

tests/html sont des tests manuels que vous pouvez exécuter avec ./mach run tests/html/permission-test.html . Je viens de remarquer les utilisations de as_window() dans le code des autorisations (https://github.com/servo/servo/blob/fd174c54ef4fa6574ae782dacccaeccd14abb936/components/script/dom/permissions.rs#L321-L322) qui feront ce code panique à chaque fois qu'il est appelé dans une étendue non-fenêtre. Nous devons les corriger en déplaçant l'API permission_state_invocation_results vers GlobalScope au lieu de Window.

Merci d'avoir signalé l'échec de test-background-fetch-permission.html - j'ai déposé #23645 pour le réparer.

Merci. Je vois.

ce qui fera paniquer ce code à chaque fois qu'il est appelé dans une portée non-fenêtre. Nous devons les corriger en déplaçant l'API permission_state_invocation_results vers GlobalScope au lieu de Window.

Cela devrait-il être un PR séparé ou une partie du même ?

Cela devrait certainement être un commit séparé, mais cela pourrait aussi être un PR séparé. Je ne m'attendrais pas à ce que les tests automatisés soient bons pour vérifier ce problème (# 23057), car le code d'autorisation supprime l'interface utilisateur d'invite lors de l'exécution sans tête.

Le correctif proposé dans #23651 était sur la bonne voie, mais j'ai eu quelques commentaires de révision qui doivent être traités et l'auteur est passé à autre chose.

@peacerebel Cela pourrait être un bon prochain numéro sur

@PeaceRebel Cela pourrait être un bon prochain numéro sur

Je regarderai ça demain.

@highfive m'assigne

Salut @PeaceRebel ! Merci de l'intérêt que vous portez à travailler sur ce problème. Il vous est désormais attribué !

Annulation pour cause d'inactivité.

J'ai rebasé les modifications dans le PR au-dessus de master sur ma branche https://github.com/iulianR/servo/tree/issue-23057-tinifiledialogs. Je peux essayer de répondre aux commentaires et faire un nouveau PR si cela vous convient.

Ce serait génial!

J'ai mis à jour ma branche avec un commit qui délègue le formatage de la chaîne aux embedders.

Maintenant, je suis un peu coincé en essayant d'aborder la deuxième partie du PR. Je ne sais pas si j'ai besoin d'une nouvelle méthode sur HostTrait , ou si je dois utiliser/mettre à jour la prompt_yes_no() qui existe déjà. Peut-être pourriez-vous écrire la signature de la méthode pour moi. Merci.

Je pense que l'utilisation de la méthode prompt_yes_no semble bien pour le moment.

Cette page vous a été utile?
0 / 5 - 0 notes