Bug 164718 - [GTK] webkit_navigation_action_get_modifiers() returns 0 for JavaScript events
Summary: [GTK] webkit_navigation_action_get_modifiers() returns 0 for JavaScript events
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-14 11:06 PST by antoyo
Modified: 2019-05-02 16:20 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description antoyo 2016-11-14 11:06:12 PST
Hello.
Is it normal that `webkit_navigation_action_get_modifiers()` always returns 0 for JavaScript event (even when ctrlKey is set to true)?
If yes, is there a way to get this value in the UI process for a JavaScript event?
Thanks.
Comment 1 Michael Catanzaro 2017-05-07 19:32:11 PDT
I don't know, but I guess this is a bug.
Comment 2 Carlos Garcia Campos 2017-05-11 01:09:29 PDT
Could you provide a small test case to reproduce the issue?
Comment 3 antoyo 2017-05-16 17:09:39 PDT
So, I made an example [here](https://github.com/antoyo/webkit-bug) (sorry, it is written in Rust, but it should be easy to understand).

You can see that there's a web extension that [clicks on a link](https://github.com/antoyo/webkit-bug/blob/master/webkit-bug-extension/src/lib.rs#L21-L22) and the `ctrlKey` parameter is set to true.
The JavaScript will show that this parameter is indeed true [here](https://github.com/antoyo/webkit-bug/blob/master/tests/index.html#L7).
It works the same as when the user ctrl-click manually the link.

However, the difference is that `webkit_navigation_action_get_modifiers()` [will return 0](https://github.com/antoyo/webkit-bug/blob/master/src/main.rs#L26) when the click was triggered by the web extension, while it will return 4 on a manual ctrl-click.

This might be because this API matches the JavaScript API and it might be disallowed in JavaScript for security reasons.
However, I believe it should be possible to simulate a ctrl-click in a web extension.

If you need more info, feel free to ask.
Comment 4 Carlos Garcia Campos 2017-05-17 01:07:47 PDT
Ok, this is not a bug, but the expected behavior. Events not generated by a real user actions are considered untrusted, they have the isTrusted read-only property set to true. The NavigationAction always returns NoButton and 0 modifiers for mouse buttons that are not trusted. See bug #154571.
Comment 5 antoyo 2017-05-17 04:18:28 PDT
I'm not authorized to see this bug.
But, in any case, surely there's an alternative way to simulate a ctrl-click?

I can understand that events generated by JavaScript are untrusted, but we're in a web extension, here.
A web extension can access any file of the filesystem while JavaScript cannot, for instance, so why should events generated by a web extension be untrusted?

Thanks.
Comment 6 Michael Catanzaro 2017-05-17 05:44:53 PDT
The DOM API you're using from the web extension is exactly the same as the DOM API available to JavaScript... just another way of accessing it.

Perhaps we need a way to override this. You seem to have a valid use-case.
Comment 7 Carlos Garcia Campos 2017-05-17 23:12:27 PDT
(In reply to antoyo from comment #5)
> I'm not authorized to see this bug.

See http://trac.webkit.org/changeset/197150

> But, in any case, surely there's an alternative way to simulate a ctrl-click?

Form the UI process you can send events to the widget. That's what we do for our tests or for web automation. That depends on the toolkit, of course, GTK+ in this case.

> I can understand that events generated by JavaScript are untrusted, but
> we're in a web extension, here.
> A web extension can access any file of the filesystem while JavaScript
> cannot, for instance, so why should events generated by a web extension be
> untrusted?

Yes, essentially it's exactly the same, it's the same code called from two different bindings (JS and GObject), but I agree that GOboject bindings can only be used from a compiled web extension that we are currently considering trusted for many other things. So, we could probably change the DOM API implementation to generate trusted events, or at least add a way to do so.

> Thanks.
Comment 8 Michael Catanzaro 2017-05-18 08:44:35 PDT
(In reply to Carlos Garcia Campos from comment #7)
> So, we could probably change the DOM API
> implementation to generate trusted events, or at least add a way to do so.

So should we reopen this?
Comment 9 Michael Catanzaro 2017-05-18 08:45:28 PDT
Hm... if we're planning to replace the entire DOM API with a JS API, then how would we ensure this new trusted events bindings are accessible to normal webpages but not the trusted web extension?
Comment 10 antoyo 2017-05-24 16:30:12 PDT
Creating trusted events from a Firefox add-on is possible, so I believe it should be possible in a webkit extension.