I don't know, but I guess this is a bug.
Could you provide a small test case to reproduce the issue?
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.
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.
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.
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.
I'm not authorized to see this bug.
But, in any case, surely there's an alternative way to simulate a ctrl-click?
Perhaps we need a way to override this. You seem to have a valid use-case.
(In reply to antoyo from comment #5)
> I'm not authorized to see this bug.
> 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.
> we're in a web extension, here.
> cannot, for instance, so why should events generated by a web extension be
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.
(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?
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?
Creating trusted events from a Firefox add-on is possible, so I believe it should be possible in a webkit extension.