Core_View doesn't work in packaged chrome app (w/ background page)

[dborkan]

The default implementation of Core_View that gets built into freedom-for-chrome.js does not work in packaged chrome apps using a background page.

Some issues I'm seeing:

• The onOpen method in Core_View.provider appends a new child to document.body. However that is just appending to the document.body in the background HTML page - not something that is ever displayed to the user.
• The page and resources URLs are all being prefixed with a chrome-extension://..id.. URL, however those URLs cannot be opened in a browser tab for packaged apps (they redirect to chrome://invalid. I believe for "hosted" apps you can get around this by specifying web_accessible_resources in the manifest, but that's not available for packaged apps).

I've hacked together a simple core.view provider for Chrome that uses chrome.app.window.create to display views inside a Chrome app, after removing chrome-extension://..id../ from the URLs. Any thoughts on whether this should be submitted to freedom-for-chrome, or if it should just live in uProxy as our own custom core.view provider?

Somewhat related to Core_View issues in freedom-for-firefox, freedomjs/freedom-for-firefox#83

[agallant]

In principle I think this should live in freedom-for-chrome, though as you noted in the snippet you emailed me the approach you have now may be a little uProxy-specific. Parametrizing the path may be the way to make it work more generally.

[agallant]

On further reflection, if the fix can be small enough it may be best just to keep the core freedom provider still. It seems like the main issue is the path - do you think just putting that fix in would work? E.g. https://github.com/freedomjs/freedom/tree/soycode-coreview

We should still do some due diligence about how general the '../' path prefix should really be, but if it can be somewhat general then this approach may be easiest. Let me know your thoughts, thanks!

[agallant]

Actual commit - freedomjs/freedom@6d84af1

[dborkan]

I think those changes for the path would help us but that's not all that is missing to run in a Chrome app. With those changes, it's still trying to append the view as div to the document.body. However in the uProxy Chrome app, the document.body just refers to some hidden webpage used by the app's background page, not something ever visible to the user. I think we would either need a way to display this page to the user (in the onOpen call) or we would need to launch a new popup/tab/etc using something like chrome.app.window.create

[agallant]

Longshot possibility - do you think we could use chrome.tabs.executeScript (https://developer.chrome.com/extensions/content_scripts#pi) to get Chrome to execute the code in the proper environment? I imagine it is probably technically possible, but am unsure if it fits into the existing permissions/model of the uProxy Chrome app.

[agallant]

Actually had a better thought - freedomjs/freedom@befc4d7

If that doesn't work as-is, then hopefully just creating a new appwindow (i.e. chrome.app.window.create) and then using that instead of current() will work. That approach may require changing the code to close it, though.