Closed Bug 810036 Opened 12 years ago Closed 11 years ago

Browser API: expose child <body> dimension and dimension changes to the parent

Categories

(Firefox OS Graveyard :: General, defect)

Product:
Firefox OS Graveyard
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: timdream, Unassigned)

References

Details

Here is a proposed addition to mozbrowser API to expose the child <body> dimension and dimension changes to the parent. For B2G Keyboard apps, where keyboard app is the child frame and the System app is the parent, we will need the information in the System app keyboard manager, so that app frame can be resized and not being covered by the keyboard. A conventions should also established to all keyboard apps that it should absolute position it's <body> element to the space where it think it should be exclusively for keyboard -- on a mobile it is expected that the position be the bottom part of the keyboard frame (which occupies the entire keyboard but kept transparent) The proposed browser API is as follows: frame.addBodyElementDimensionObserver(callback); frame.removeBodyElementDimensionObserver(callback); callback receives an object with offsetWidth, offsetHeight, offseTop, and the offsetLeft properties, with the same values from the properties of the body element of the same name. To implement this API, when |addBodyElementDimensionObserver| is called, browserElementChild.js will attach a mutation observer to content.document.body. When mutation observer triggers the callback, the script should gather the properties value and send them back to browserElementParent.js. If there are no observers on the parent, the child should disconnect the mutation observer and remove it. I am not sure if it's the best way to do it, I am only thinking about this in a way that can be done by touch the browserElement*.js only. Feedback welcome!
:bz, I am told by :jlebar that you would have some inputs on this. What do you think about the approach?
Sorry for the lag; I'm about a day and a half behind on mail, but hope to fix that on Sunday... First question: what's the security model here? We're not exposing this API to untrusted code, right?
> We're not exposing this API to untrusted code, right? Right; only to embedders of <iframe mozbrowser>, which already lets you do much scarier things than this (read location cross-origin, send arbitrary keyboard and mouse events to content, take screenshots, etc).
Blocks: browser-api
And I assume you want to avoid exposing direct access to the HTMLBodyElement because you don't want people coming to rely on it? Adding an API for current dimensions is not too bad (though I recommend getBoundingClientRect instead of the totally-broken offset*). Adding an API that triggers when the dimensions _change_ is a totally different kettle of fish. You'd need to detect that, for one thing. Are we really trying to measure the <body> dimensions as opposed to viewport dimensions or document size or various other sorts of things one might care about?
> And I assume you want to avoid exposing direct access to the HTMLBodyElement because you > don't want people coming to rely on it? It may be OOP. > Adding an API that triggers when the dimensions _change_ is a totally different kettle > of fish. You'd need to detect that, for one thing. I think the idea was that we'd require the <body> element to be absolutely positioned and sized, which would let us detect this? If we could get around that requirement, that might be nice.
Even that's not enough, unless you're requiring the size to be in the inline style or something...
(In reply to Boris Zbarsky (:bz) from comment #4) > Adding an API for current dimensions is not too bad (though I recommend > getBoundingClientRect instead of the totally-broken offset*). That's a good idea -- let's use getBoundingClientRect instead. > Adding an API that triggers when the dimensions _change_ is a totally > different kettle of fish. You'd need to detect that, for one thing. > > Are we really trying to measure the <body> dimensions as opposed to viewport > dimensions or document size or various other sorts of things one might care > about? The viewport dimension will be fixed to the entire screen. The document size (scroll height/width) is not expected to change at all. The whole idea is to allow keyboard app to draw it's overlaying content on top of everything but with the ability to tell the system which part of the screen should be reserved to keyboard exclusively, hence the <body>. (In reply to Boris Zbarsky (:bz) from comment #6) > Even that's not enough, unless you're requiring the size to be in the inline > style or something... Correct me if I am wrong, my understanding to mutation observer is that every change that will result dimension change (child node change, attribute (className, inline style), character data) is detectable. Use of inline style will not be required. I do worry that mutation observer will be a overkill for this; and there will be loop holes, like changing a class name on <html> that will enable a |html.my_class body {}| selector -- if there is any other signal/message from layout that we could use in browserElementChild.js, that would be a good news!
> every change that will result dimension change (child node change, attribute (className, > inline style), character data) That's missing state changes, downloadable fonts loading, stylesheets loading, CSSOM changes to stylesheets, user changing zoom, and probably other things I'm forgetting right now... > and there will be loop holes Right. Just making sure you're ok with them. ;) > if there is any other signal/message from layout that we could use in > browserElementChild.js It really shouldn't be hard to add a resize observer mechanism in layout that just saves a rect and checks it after every reflow.... David, any objections to doing that?
Bug 891763 created to replace the proposal here.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.