Servo: Remove use of tinyfiledialogs from script code

Created on 19 Mar 2019  ·  36Comments  ·  Source: servo/servo

This is very similar to https://github.com/servo/servo/issues/20428 and https://github.com/servo/servo/issues/20429. Right now the DOM permissions code directly invokes the tinyfiledialogs library to create a permission UI. Instead, we should be sending a message to the embedder and making the embedding layer create the UI.

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

Most helpful comment

Try running Servo with --pref dom.permissions.enabled.

All 36 comments

@highfive: assign me

Hey @ejmg! Thanks for your interest in working on this issue. It's now assigned to you!

Unassigning per request on IRC.

@highfive: assign me

Hey @cdeler! Thanks for your interest in working on this issue. It's now assigned to you!

Hello @jdm ,

I have a draft implementation locally. Do you know, how can I check it locally?

@cdeler You might try running a page that calls navigator.permissions.request({'name': 'geolocation'}) to verify that the modified code runs correctly by adding println in the appropriate places.

Are you still working on this @cdeler?

I am interested in this one and looked already into it, but I I may need some guiding if this is possible.
The first issue I am facing is how can I use PermissionStatusBinding::PermissionState in _ports/glutin/browser.rs_

@kleinph You will need to define an equivalent enum in embedder_traits, which is available to both script and ports/glutin, and then convert between the two enums as needed.

OK, I will try that @jdm . Thanks!

@highfive: assign me

Hey @gatoWololo! Thanks for your interest in working on this issue. It's now assigned to you!

I have a general sense of how to do it. One thing that is not clear to me is how to send the message to the embedder. Both #20428 and #20429 get an embedder_proxy object directly from the constellation in servo/lib.rs. However, seeing how Pemisssions structs are created, there is quite a layers before finally getting to 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.

I saw there is also window.send_to_embedder(msg);, so I could send a message but how do I get a response back from the embedder?

Based on the conversation here: https://github.com/servo/servo/pull/20480 it seems passing the embedder_proxy was the agreed upon way?

The message to the embedder can contain an IpcSender, and the permissions code can either synchronously block on receiving the response, or hook the receiver up to the ipc router and inject an event into the thread's event loop when a response is received.

As for how to communicate with the embedder, I think adding a send_to_embedder API to GlobalScope and storing the embedder channel in GlobalScope would be sensible. Then the permissions code should be able to use something like self.global().send_to_embedder(...).

The message to the embedder can contain an IpcSender

Ah, I see.

Sounds good. I'll work from here!

So I think I have something working. But I'm not really able to test it. I thought it was my code, but using a unmodified version of Servo I still get the 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

Where permissionTest.html is just a copy of servo/tests/html/permission-test.html.

window.navigator.permissions is undefined

I guess you might need to enable it

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

Try running Servo with --pref dom.permissions.enabled.

I'm having a hard time testing my implementation. Opening a html page which calls permissions works (yay!). But I'm unable to properly run tests related to this feature. So I find tests which call "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) {
...

I then try to run some of this wpt tests:

> ./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

The first one just crashes. The second one crashes but it's expected? So I'm not convinced I have tested anything.

There are also some tests like tests/html/permission-test.html which are not part of wpt. So I'm not sure how to run them.

tests/html are manual tests that you can run with ./mach run tests/html/permission-test.html. I just noticed the uses of as_window() in the permissions code (https://github.com/servo/servo/blob/fd174c54ef4fa6574ae782dacccaeccd14abb936/components/script/dom/permissions.rs#L321-L322) which will make that code panic any time it's called in a non-Window scope. We need to fix those by moving the permission_state_invocation_results API to GlobalScope instead of Window.

Thanks for pointing out the failure in test-background-fetch-permission.html - I've filed #23645 to fix it.

Thanks. I see.

which will make that code panic any time it's called in a non-Window scope. We need to fix those by moving the permission_state_invocation_results API to GlobalScope instead of Window.

Should this be a separate PR or part of the same one?

It should certainly be a separate commit, but it could be a separate PR too. I wouldn't expect the automated tests to be good for verifying this issue (#23057), because the permissions code suppresses the prompting UI when running headlessly.

The proposed fix in #23651 was on the right track, but I had some review comments that need to be addressed and the author has moved on to other things.

@peacerebel This might be a good next issue to work on!

@PeaceRebel This might be a good next issue to work on!

Will take a look at this tomorrow.

@highfive assign me

Hey @PeaceRebel! Thanks for your interest in working on this issue. It's now assigned to you!

Unassigning due to inactivity.

I rebased the changes in the PR on top of master on my branch https://github.com/iulianR/servo/tree/issue-23057-tinifiledialogs. I can try to address the comments and make a new PR if it's fine with you.

That would be great!

I updated my branch with a commit that delegates the string formatting to embedders.

Now I'm a bit stuck trying to address the second part of the PR. I am not sure if I need a new method on HostTrait, or if I should use/update the prompt_yes_no() one that already exists. Maybe you could write the method signature for me. Thanks.

I think using the prompt_yes_no method sounds fine for now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kmcallister picture kmcallister  ·  4Comments

ayelen912 picture ayelen912  ·  3Comments

larsbergstrom picture larsbergstrom  ·  3Comments

SimonSapin picture SimonSapin  ·  3Comments

Grishy picture Grishy  ·  3Comments