Servo: Убрать использование tinyfiledialogs из кода скрипта

@highfive :

Привет @ejmg! Благодарим за интерес к работе над этой проблемой. Теперь он назначен вам!

Отмена назначения по запросу в IRC.

@highfive :

Привет, @cdeler! Благодарим за интерес к работе над этой проблемой. Теперь он назначен вам!

Привет @jdm!

У меня есть локальный черновик реализации. Вы знаете, как я могу это проверить на месте?

@cdeler Вы можете попробовать запустить страницу, которая вызывает navigator.permissions.request({'name': 'geolocation'}) чтобы убедиться, что измененный код работает правильно, добавив println в соответствующие места.

Вы все еще работаете над этим @cdeler?

Я заинтересован в этом, и я уже изучал его, но мне может потребоваться какое-то руководство, если это возможно.
Первая проблема, с которой я столкнулся, - как использовать PermissionStatusBinding::PermissionState в _ports / glutin / browser.rs_

@kleinph Вам нужно будет определить эквивалентное перечисление в embedder_traits, которое доступно как для скрипта, так и для портов / glutin, а затем преобразовать эти два перечисления по мере необходимости.

Хорошо, я попробую этот @jdm . Спасибо!

Пример отправки сообщения из сценария / DOM в устройство для внедрения можно найти по адресу https://github.com/servo/servo/blob/9d9fff3b0ad843286875051e6544b3d4750d6238/components/script/dom/windowproxy.rs#L264

@highfive :

Привет, @gatoWololo! Благодарим за интерес к работе над этой проблемой. Теперь он назначен вам!

У меня есть общее представление о том, как это делать. Мне непонятно, как отправить сообщение устройству для внедрения. И # 20428, и # 20429 получают объект embedder_proxy непосредственно из созвездия в servo/lib.rs . Однако, видя, как создаются структуры Pemisssions, есть довольно много слоев, прежде чем наконец добраться до 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.

Я видел, что есть также window.send_to_embedder(msg); , поэтому я могу отправить сообщение, но как мне получить ответ от устройства для встраивания?

Основываясь на беседе здесь: https://github.com/servo/servo/pull/20480, кажется, что передача embedder_proxy была согласованным способом?

Сообщение для встраивающего устройства может содержать IpcSender, а код разрешений может либо синхронно блокироваться при получении ответа, либо подключать получателя к маршрутизатору ipc и вставлять событие в цикл обработки событий потока при получении ответа.

Что касается взаимодействия с устройством для внедрения, я думаю, что было бы разумно добавить API send_to_embedder в GlobalScope и сохранить канал для внедрения в GlobalScope. Тогда код разрешений должен иметь возможность использовать что-то вроде self.global().send_to_embedder(...) .

Сообщение для встраивающего устройства может содержать IpcSender.

Ах я вижу.

Звучит отлично. Я буду работать отсюда!

Так что я думаю, что у меня что-то работает. Но я не могу это проверить. Я думал, что это мой код, но, используя неизмененную версию Servo, я все равно получаю ошибку:

[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 - это просто копия servo/tests/html/permission-test.html .

window.navigator.permissions is undefined

Я думаю, вам может потребоваться включить его

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

Попробуйте запустить Servo с --pref dom.permissions.enabled .

Мне сложно тестировать свою реализацию. Открытие html-страницы, которая вызывает разрешения, работает (ура!). Но я не могу правильно запустить тесты, связанные с этой функцией. Итак, я нахожу тесты, которые вызывают "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) {
...

Затем я пытаюсь запустить некоторые из этих тестов 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

Первый просто вылетает. Второй вылетает, но это ожидаемо? Так что я не уверен, что что-то тестировал.

Есть также некоторые тесты, такие как tests/html/permission-test.html которые не являются частью wpt. Так что я не знаю, как их запустить.

tests / html - это ручные тесты, которые можно запустить с помощью ./mach run tests/html/permission-test.html . Я только что заметил использование as_window() в коде разрешений (https://github.com/servo/servo/blob/fd174c54ef4fa6574ae782dacccaeccd14abb936/components/script/dom/permissions.rs#L321-L322), который сделает этот код вызывает панику всякий раз, когда он вызывается в области, отличной от Window. Нам нужно исправить это, переместив permission_state_invocation_results API в GlobalScope вместо Window.

Спасибо, что указали на сбой в test-background-fetch-permission.html - я подал # 23645, чтобы исправить это.

Спасибо. Понятно.

что вызовет панику этого кода каждый раз, когда он вызывается в области, отличной от Window. Нам нужно исправить это, переместив API permission_state_invocation_results в GlobalScope вместо Window.

Это должен быть отдельный пиар или часть одного и того же?

Это, безусловно, должен быть отдельный коммит, но это может быть и отдельный пиар. Я бы не ожидал, что автоматические тесты будут хороши для проверки этой проблемы (# 23057), потому что код разрешений подавляет подсказку пользовательского интерфейса при автономной работе.

Предлагаемое исправление в # 23651 было правильным, но у меня были некоторые комментарии к обзору, которые необходимо учесть, и автор перешел к другим вещам.

@peacerebel Это может быть хорошей следующей проблемой, над которой стоит поработать!

@PeaceRebel Это может быть хорошей следующей проблемой, над которой стоит поработать!

Взглянем на это завтра.

@highfive назначьте меня

Привет, @PeaceRebel! Благодарим за интерес к работе над этой проблемой. Теперь он назначен вам!

Отмена назначения из-за бездействия.

Я перебазировал изменения PR поверх master в моей ветке https://github.com/iulianR/servo/tree/issue-23057-tinifiledialogs. Я могу попытаться ответить на комментарии и сделать новый пиар, если вас это устраивает.

Это было бы прекрасно!

Я обновил свою ветку с помощью коммита, который делегирует форматирование строки встраивающим устройствам.

Теперь я немного застрял, пытаясь заняться второй частью PR. Я не уверен, нужен ли мне новый метод для HostTrait , или мне следует использовать / обновить уже существующий prompt_yes_no() . Может быть, вы могли бы написать для меня подпись метода. Спасибо.

Я думаю, что использование метода prompt_yes_no сейчас звучит нормально.