Functions for accessing app window properties, and modifying AppWindow-specifics

Functions for accessing app window properties, and modifying AppWindow-specifics
such as min/max size.

was: chrome.appWindow.{update|getProperties|getAll}()
now: chrome.app.window.AppWindow.get{Id,Position,Size,...}()

First cut is an API flavour with some encapsulation of 2D (x,y) values
but otherwise leaving properties "unbagged"

BUG=134068
closed: split into https://chromiumcodereview.appspot.com/10910304/, and a later CL that will diverge a lot from this

[tapted, 2012-09-13 09:06:09]

Sill a WIP (and still lots of chrome internals for me to absorb!).

This also adds a possible solution to (new issue) http://crbug.com/148814
(app.window.current() should return the same thing passed to the
app.window.create() callback).

This version change decorates the object with direct access to (possibly stale)
.width, .height, .windowKey (the `id` passed to create()), and also viewId
(routingID, used to access the cache). This also "protects" the API from user
changes -- the object is frozen and "dynamic" things (width/height) are accessed
via getters which access the cache (indexed by viewId).

Adding an "onMove" callback might be better left as a \todo since it will be a
much bigger CL.

Example usage:

var w = chrome.app.window.current();
console.log("1. (%dx%d) {%s, %d}",
            w.width, w.height,
            w.windowKey, w.viewId);


The cache approach also gives us a way to address http://crbug.com/148594
(window height including the height of the injected title bar, which might
change). But it's not in there yet.

One issue that came up (and did my head in a bit..) is the behavior on a
right-click reload while loading an unpackaged app in developer mode. There's a
placeholder for dealing with this case (and some log output..). If we want to
support that, we might need some IPC to update the cache as a 'bag', when it's
detected that the cache has been cleared due to the reload. Or maybe there's
some shortcut to this that I don't know about.

I'm probably doing lots of other silly things -- please let me know!

[Mihai Parparita -not on Chrome, 2012-09-16 05:31:39]

I think this is headed in the right direction. I would suggest doing just one
simple property for now (windowState?), so that the intent of the CL is easier
to follow.

As to where to put makeAppWindow, it might make sense to rename
currentWindowInternal to be a more general appWindowInternal namespace, so that
both the cache and the current window bindings can go there.

Also, I'm not sure if freezing the window is. Web developers are generally used
to treating all objects (even DOM wrappers) as things they can add random
properties to. What is freezing meant to prevent?

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
File chrome/common/extensions/api/app_window.idl (right):

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
chrome/common/extensions/api/app_window.idl:62: // The identity of this window
used on creation for persisting state
Nit: this was called "id" in the create params, so it should have the same name
here.

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
chrome/common/extensions/api/app_window.idl:84: DOMString windowState;
Why not use the WindowState enum here?

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
File chrome/renderer/resources/extensions/app_window_custom_bindings.js (right):

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
chrome/renderer/resources/extensions/app_window_custom_bindings.js:108: //
NOTE(tapted) this version should solve crbug.com/148814
Can you break out the fix for this bug into a separate CL (possibly to be landed
first). I'm finding the cache changes that span multiple JS context hard to
follow, and it might be easier if they were untangled from the property ones.

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
chrome/renderer/resources/extensions/app_window_custom_bindings.js:148: var
appWindow = chrome.app.window.current();
Do you need to look up the current window? It seems like using newWindow in the
closure would get you the right window that is being resized.

[tapted, 2012-09-17 08:48:56]

I've created http://codereview.chromium.org/10910304 to address the cache
changes (for http://crbug.com/148814 )

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
File chrome/common/extensions/api/app_window.idl (right):

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
chrome/common/extensions/api/app_window.idl:62: // The identity of this window
used on creation for persisting state
On 2012/09/16 05:31:39, Mihai Parparita wrote:
> Nit: this was called "id" in the create params, so it should have the same
name
> here.

sticking with `id` in crrev.com/10910304/

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/common/exten...
chrome/common/extensions/api/app_window.idl:84: DOMString windowState;
On 2012/09/16 05:31:39, Mihai Parparita wrote:
> Why not use the WindowState enum here?

will do

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
File chrome/renderer/resources/extensions/app_window_custom_bindings.js (right):

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
chrome/renderer/resources/extensions/app_window_custom_bindings.js:108: //
NOTE(tapted) this version should solve crbug.com/148814
On 2012/09/16 05:31:39, Mihai Parparita wrote:
> Can you break out the fix for this bug into a separate CL (possibly to be
landed
> first). I'm finding the cache changes that span multiple JS context hard to
> follow, and it might be easier if they were untangled from the property ones.

Good call -- I've created http://codereview.chromium.org/10910304

https://chromiumcodereview.appspot.com/10915085/diff/1007/chrome/renderer/res...
chrome/renderer/resources/extensions/app_window_custom_bindings.js:148: var
appWindow = chrome.app.window.current();
On 2012/09/16 05:31:39, Mihai Parparita wrote:
> Do you need to look up the current window? It seems like using newWindow in
the
> closure would get you the right window that is being resized.

current() had some logic to deal with developer-reloads breaking the cache, but
that can probably be deferred.