Bug 164718 – [GTK] webkit_navigation_action_get_modifiers() returns 0 for JavaScript events

• Status: REOPENED
• Component: WebKitGTK

[antoyo]

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.

[Michael Catanzaro]

I don't know, but I guess this is a bug.

[Carlos Garcia Campos]

Could you provide a small test case to reproduce the issue?

[antoyo]

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.

[Carlos Garcia Campos]

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.

[antoyo]

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.

[Michael Catanzaro]

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.

[Carlos Garcia Campos]

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

[Michael Catanzaro]

(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?

[Michael Catanzaro]

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?

[antoyo]

Creating trusted events from a Firefox add-on is possible, so I believe it should be possible in a webkit extension.