Closed
Bug 772452
Opened 12 years ago
Closed 12 years ago
[BrowserAPI] Let the embedder fire events down to the embedded content window
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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.
Reporter | ||
Comment 1•12 years ago
|
||
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.
Reporter | ||
Updated•12 years ago
|
Blocks: browser-api
Comment 2•12 years ago
|
||
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?
Reporter | ||
Comment 3•12 years ago
|
||
> 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?
Comment 4•12 years ago
|
||
(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.
Comment 5•12 years ago
|
||
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.
Reporter | ||
Comment 6•12 years ago
|
||
(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.
Comment 7•12 years ago
|
||
(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?
Reporter | ||
Comment 8•12 years ago
|
||
> 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?
Comment 9•12 years ago
|
||
(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.
Reporter | ||
Comment 10•12 years ago
|
||
> 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.
Comment 11•12 years ago
|
||
(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 ;)
Comment 12•12 years ago
|
||
(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.
Reporter | ||
Comment 13•12 years ago
|
||
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.
Reporter | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•11 years ago
|
Component: DOM: Mozilla Extensions → DOM
Assignee | ||
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•