1176644 - Keydown events need additional context when bubbled up through frame boundaries

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect)

Description

[Kevin Grandon]

In an OOP setup, keyboard events are bubbled up to a parent mozbrowser iframe. Currently the events are passed to the parent mozbrowser with a target equal to the containing iframe. In order to properly utilize these events, we need some additional context, such  as the type of element. This is necessary so that the parent frame can perform different actions based on the type of element that the keydown is for. E.g., the parent frame may behave differently if a keydown event fires inside of an input or textarea, instead of a link.

Ideally the parent frame would receive a reference of the element. Maybe we could put this in either event.currentTarget or event.explicitOriginalTarget. If that's not possible, a nodeName might suffice. Hiding this behind a permission or only for certified apps is fine for our use-case.

Comment 1

[Kevin Grandon]

Fabrice or Paul - would either of you guys be interested in helping here, or redirecting to someone who knows this code?

I also realized that we need to know when we're in a [contenteditable] situation. Maybe we could pass in some property as to whether or not we were inside an editable field (with a cursor) when the parent frame gets the event?

Relevant browser.html discussion: https://github.com/mozilla/browser.html/issues/432

Comment 2

[Paul Rouget [:paul]]

> In order to properly utilize these events, we need some additional context, such  as the type of element.

That would mean delaying all the events until consumed by the child process.

> Ideally the parent frame would receive a reference of the element

Not possible. The DOM is in a different process.

> a nodeName might suffice

See the _buildMenuObj function that does something like that for the contextmenu event: https://dxr.mozilla.org/mozilla-central/search?q=_buildMenuObj&case=true

---

Can you give an example of things you might want to do with this kind of information?

The way it works in Firefox is that some predefined events have a delayed bubble phase. The event bubble up only once it's been consumed by the child process, and it's up to the child process to preventDefault the event if necessary.

Comment 3

[Kevin Grandon]

(In reply to Paul Rouget [:paul] from comment #2)
> Can you give an example of things you might want to do with this kind of
> information?

Basically the same thing that we want to do here: https://github.com/mozilla/browser.html/issues/432

> The way it works in Firefox is that some predefined events have a delayed
> bubble phase. The event bubble up only once it's been consumed by the child
> process, and it's up to the child process to preventDefault the event if
> necessary.

I think that delaying the events here would also work for us. I tried using a listener inside the child, but currently key events get bubbled to the parent even after a stopPropagation call.

Comment 4

[[:fabrice] Fabrice Desré]

I don't have anything to add to what Paul said.