chrome.windows.* API and packaged app windows

[Lionel G]

Hi,

Reading https://developer.chrome.com/extensions/windows it sounds like this API is designed just to interact with browser windows.

Would it make sense to also include application windows? In particular on ChromeOS?

There is a bug opened about enabling access to all windows : https://code.google.com/p/chromium/issues/detail?id=394341

Has anyone any input on this?

Looking forward to any comment.

Thanks,

-

Lionel

[Mike Tsao]

Depends on the use case. If it's a specific extension interacting with a specific app, then they can do what they want already with messaging. If it's a general need to rearrange all Chrome-controlled windows on the desktop (e.g., a hypothetical window-arranger extension, which sounds like that Divvy thing linked in the bug report), then that's going to require some thought, particularly because of the security and privacy issues involved in giving one item information about other items in the user's profile. Which use case are you interested in?

[Lionel G]

Hi Mike,

I'm interested in the later.

That's interesting that you mention the security and privacy issues.

I was wondering because, let's say you have the Gmail packaged app and a browser window with a tab opened on gmail.com, what the reasoning for allowing the chrome.windows API to see one window but not the other?

Thanks

[Benjamin Kalman]

This is a good question. I don't see much problem security wise (much as it sounds scary) nor privacy.

The main issue I see is that chrome.windows API is designed to interact with the fairly primitive and entirely user-managed Chrome windows, whereas App windows have a relatively complex set of configuration options, like bounds restrictions, and the ability to move themselves. We'd need to tread carefully.

[Lionel G]

Playing the devil's advocate here, to some extents browser windows have bounds restrictions too.

Regarding the ability of applications to move their own window, are you referring to the draggable window areas [1]?

Do you think adding the BoundSpecification [2] object to the chrome.windows objects [3] is the way to go to start exposing more complex window information?

Thanks,

-

Lionel

[1] : https://developer.chrome.com/apps/app_window

[2] : https://developer.chrome.com/apps/app_window#type-BoundsSpecification

[3] : https://developer.chrome.com/extensions/windows#type-Window

[Wolf War]

I don't think mixing chrome.windows and chrome.app.window is a good idea. They belong to different development streams, with it's own purpose. 

Chrome.windows is light weight API and imho should stay that way. 

What I would like to see is that chrome packaged apps have access to majority of chrome API's, including chrome.windows...tabs etc.

and vice versa, that chrome have access to chrome.app API's (chrome.app.window )

This way, everything stays as it is, with extra stuff when needed/wanted.

[Mike Tsao]

It's a question of expectations. Extensions have access to your browser content. They make your web browsing better. That's understood by all sophisticated users and many casual users, and it's unlikely that it would surprise anyone to learn that a given extension might have access to your "web stuff," to use that term loosely.

Chrome Apps, on the other hand, are designed to be entirely isolated from your browsing experience, like a native desktop app. The fact the Chrome Apps happen to use Chrome as their runtime is just an implementation detail. Apps can't see your browser profile's cookies. Browser tabs know nothing about Apps. The platform has presented itself as a native-app solution, and it would violate user expectations to give Chrome special API powers over certain "native" apps (in quotes because they're actually Chrome Apps, unbeknownst to the typical user), while other native apps were still invisible to Chrome. That's the gist of the privacy issue.

As for security, a window manager has all sorts of crazy abilities. It could put up a malicious window right in front of a different app from your bank that's asking for your bank password. It could hide other apps' attempts to warn you of dangerous things. None of these problems is insurmountable, but they're why it's not a simple decision to flip a bit allowing chrome.windows to access non-tab windows.

[Benjamin Kalman]

Thinking in terms of ChromeOS is more interesting than on other platforms, where the distinction between "browsing experience" and "app experience" isn't obvious (in terms of user expectations). I think it's reasonable to give extensions the power to move around and close ChromeOS windows. Other windows, that is. chrome.app.window already gives an app the ability to manipulate its own windows obviously.

Lionel, by "ability to modify their own window", I mean like the ability to prevent resize. All of the configuration you have on app windows. It'd be non-trivial to add sanity checking to the chrome.window API to make sure it can't break limitations that users of the chrome.app.window API make. I'm contrasting that to the web, where a webpage has no say in whether the user decides to resize their window or not.

[Steven Bennetts]

As much as I hate to muddy the waters even further, but we really have 3 different types of windows to consider:

1. A tabbed browser window.

2a. A window associated with an "app" that uses the chrome.windows API to open a window of type "popup".

2b. An "app" that is effectively just a shortcut that is set to open in a (tabless) window.

3. A "v2" app that uses the chrome.app.window API.

Currently, if I recall correctly, the chrome.windows API has access to (1) and (2) (since internally (2) is just a browser window associated with an extension).

From a user's perspective there is almost no distinction between (2) and (3), even though internally they are implemented very differently and have very different security profiles.

As much as we would like to distinguish between "browser" windows (1,2) and "native chrome apps" (3), I don't think we really do that at all from the user's perspective on any platform. They can all be launched from the app launcher, the icons in the app launcher and in Chrome OS's shelf look the same, and while "browser" windows all have a titlebar, I think that is a subtle distinction from a user perspective.

So, FWIW, I think that the chrome.windows API should have access to v2 app windows. I would also like extensions that use potentially invasive apis like chrome.windows to have more attention brought to that when they are installed, but that is an entirely separate topic.

[Ben Wells]

Adding my 2c, I think there is some worth in providing APIs that would allow a chromeOS tiling window manager to be built (for example). Maybe this is chrome.windows, maybe it is something else.

The question I have is whether it would be worth the development and maintenance effort.

[Lionel G]

Hi Ben,

The reason I started looking into this is because some of my colleagues were interested in implementing something similar to http://mizage.com/divvy/ for ChromeOS, but the inability to position application windows was a no-go.

There is also a couple of extensions that implement a tiling window placement algorithm :

https://chrome.google.com/webstore/detail/window-tiler/icdbbdcilpcejpjggageekankfnelfpj

https://chrome.google.com/webstore/detail/window-tiler/finlcpffocibdmdkmaobgeoofbiddmfp

The second extension even deals with multiple monitor setup.

The frustrating thing is, only a few types of windows are visible to extensions, so far I've notice the devtools and application windows are not.

I think these extensions are unlikely to be used for casual browsing. And it doesn't really make sense to use them on a Win/Mac/Linux desktop were you already have an external window manager on top of which you can install things like Divvy.

But on ChromeOS, it might become a useful tool for people who use a Chromebook as a development machine.

[Benjamin Kalman]

I agree with the sentiment here. The ability to implement arbitrary window managers on ChromeOS using Extension APIs would be awesome. Justifying the development and maintenance effort is unfortunately unlikely.

[David Levin]

The plethora of window managers sounds like an awesome idea until you write an app on the platform that is anything more than one single rectangular window.

What I've seen on Linux is that there are a few window managers (the stock ones) that many people use, and then there are lots of other window managers that a few people use (ratpoison, etc). All of these window managers take a platform that is already relatively small and fragments it further -- which makes it even harder to writing a quality app for it.

dave

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Ben Wells]

Indeed. I was thinking more of the burden it would place on our platform, where every change we make to how windowing works would have to take into account the possibilities this API opens up, but there is a similar burden on apps which want to fit in well with the platform's windowing system.