Closed Bug 772452 Opened 10 years ago Closed 10 years ago

[BrowserAPI] Let the embedder fire events down to the embedded content window

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: justin.lebar+bug, Unassigned)

References

Details

The browser app wants to know when the keyboard is shown/hidden, so it can alter its UI.

But the IME is not part of the platform; Gecko doesn't know when the keyboard is or isn't displayed.

There are two things we could do here.

Door number 1: When the virtual keyboard shows itself, it somehow notifies Gecko that it's shown.  Gecko then notifies all other visible frames that the virtual keyboard is shown.

Door number 2: When the system app shows the virtual keyboard, the system app sends a message down to the frame the keyboard belongs to, using a general "send message to <iframe mozbrowser> API".

The main disadvantage of (2) is that it relies on the system app doing the right thing -- that is, "virtual keyboard shown" is not part of the platform, or the browser API.

On the other hand, since "virtual keyboard" is not part of the platform, it seems a little weird to make "virtual keyboard shown" part of the platform.

I think (2) is probably the right way to go, so I'm going to do that, unless there are objections.
Proposed API for (2) would be something like:

  Embedder:
    iframe.sendMessage({name: "virtual keyboard visibility change", visible: true});

  Embeddee:
    window.addEventListener("mozbrowserembeddermessage", function(e)  {
      if (e.detail.name == 'virtual keyboard visibility change') {
        // check e.detail.visible
      }
    });

All messages from the embedder would be mozbrowserembeddermessage events, so the embedder can't fake any existing events in the embeddee.
Blocks: browser-api
The problem with (2) is that we might creating Gaia specific protocol here. As a Gaia dev I am all for it but I can think of some people that would object this.

Also I have a question: is this event cancellable?
> The problem with (2) is that we might creating Gaia specific protocol here. As a Gaia dev I am all 
> for it but I can think of some people that would object this.

Yes, agreed, that's a problem.

> Also I have a question: is this event cancellable?

We could make the event cancellable (and /asynchronously/ return to the parent whether the event was cancelled), but what use case would that serve?
(In reply to Justin Lebar [:jlebar] from comment #3)
> > Also I have a question: is this event cancellable?
> 
> We could make the event cancellable (and /asynchronously/ return to the
> parent whether the event was cancelled), but what use case would that serve?

"Please don't show the keyboard"? Yeah, the other statement that is as legit as this one would be "Please show the keyboard" ...

Don't worry about it them, just make it not cancellable.
Why does the browser app want to know when the keyboard is shown? Firefox mobile does not know when the keyboard is shown and it lives well without this information.
(In reply to Vivien Nicolas (:vingtetun) from comment #5)
> Why does the browser app want to know when the keyboard is shown?

The browser app shows a bar on top (the address bar) and a bar on the bottom (the back/forward bar).

Setting aside the question of whether this is good UI to begin with, they want to hide the bottom bar when the keyboard is shown.
(In reply to Justin Lebar [:jlebar] from comment #6)
> (In reply to Vivien Nicolas (:vingtetun) from comment #5)
> > Why does the browser app want to know when the keyboard is shown?
> 
> The browser app shows a bar on top (the address bar) and a bar on the bottom
> (the back/forward bar).
> 
> Setting aside the question of whether this is good UI to begin with, they
> want to hide the bottom bar when the keyboard is shown.

This bar will only show the location? Why hiding it?
Also, shouldn't the keyboard hide it anyway?
> This bar will only show the location? Why hiding it?

Bottom bar does not show the location.  The bottom bar shows the back/forward buttons, and maybe some other things.

> Also, shouldn't the keyboard hide it anyway?

The keyboard does not hide any part of the content window.  When the keyboard is shown, the content window shrinks.

Unless you're talking about something else?
(In reply to Justin Lebar [:jlebar] from comment #6)
> (In reply to Vivien Nicolas (:vingtetun) from comment #5)
> > Why does the browser app want to know when the keyboard is shown?
> 
> The browser app shows a bar on top (the address bar) and a bar on the bottom
> (the back/forward bar).
> 
> Setting aside the question of whether this is good UI to begin with, they
> want to hide the bottom bar when the keyboard is shown.

I understand the use case but this is very easy to resolve in the actual situation with a media query based on the size of the available space. I would suggest them to use that.
> I understand the use case but this is very easy to resolve in the actual situation with a media 
> query based on the size of the available space.

How do you generalize that to different phones?  That feels like a pretty serious hack to me.
(In reply to Justin Lebar [:jlebar] from comment #8)
> Unless you're talking about something else?

No. I'm just showing how well I know that project ;)
(In reply to Justin Lebar [:jlebar] from comment #10)
> > I understand the use case but this is very easy to resolve in the actual situation with a media 
> > query based on the size of the available space.
> 
> How do you generalize that to different phones?  That feels like a pretty
> serious hack to me.

Sure. I'm just saying that for this version this is easy to do. If we are looking for a real fix I would suggest a media query that let people know when the keyboard is up or down.
A media query is basically door number 1.  My preference would be to send an event, rather than do it through CSS, but whatever.

But it sounds like door number 2 isn't what we want.

If you guys are OK hacking around this for now, I'm OK punting on this for now.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Component: DOM: Mozilla Extensions → DOM
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.