[Merge] lp:~abreu-alexandre/webbrowser-app/fix-application-name-setup into lp:webbrowser-app

[Alexandre Abreu]

> The proposed solution only partially addresses the problem: when launching two
> instances of the webapp container on desktop (without an explicit app id), the
> second instance will open a new tab/overlay in the first instance (bug
> #1577806), because all webapps will have their app id set to the default value
> "webapp-container".
> 
> What we really need is to ensure that the app *always* has a reasonably unique
> app id, even when it was not explicitly set (typically, on a unity7 desktop).
> I propose using an encoded version of the initial URL when no app id can be
> inferred.
> 
> For example, if the webapp container was invoked like that on desktop:
> 
>     webapp-container https://ubuntu.slack.com/
> 
> We could urlencode the URL and set the app id to
> "https%3A%2F%2Fubuntu.slack.com%2F". Or, because we need to be careful about
> the length of the path where the single instance socket lives (see
> https://bazaar.launchpad.net/~phablet-team/webbrowser-
> app/trunk/view/head:/src/app/single-instance-manager.cpp#L71), we might want
> to use a short hash of that value.

I thought about that problem too and chose to handle things that way for specific reasons
(that you might not agree on :) ),

- on desktop and until we have convergence the de facto way of doing things was to use
the --app-id command line parameter, this was both a way to ensure that the user did
acknowledge and control the exact app id. I am not sure we want to add another mechanism
for that,

- encoding the url is not a good way to auto determine the APP_ID since it also breaks
as soon 2 webapps share the same homepage. it also breaks if at runtime a webapp does not
define a homepage in the command line as it is the case with a few,

> 
> I assume that for click packages that ship several desktop files, we want to
> consider those as separate apps, and thus not have them share where they write
> data (cookies, cache, etc…). In that case we want to make sure that the
> dataLocation and cacheLocation are unique for each app within a package. Is
> that guaranteed by setting the application name to appIdParts.first() ? (on a
> related note, a comment to document the exact structure of APP_ID under
> unity8/UAL would be useful for future reference)
> 
> It looks to me like SingleInstanceManager::getProfilePath() should in fact be
> moved to BrowserApplication::initialize(), because this affects all the code
> that reads/writes data, not just the single instance manager.
> 
> And since all the logic to infer the app id is specific to the webapp
> container (the app id for the browser will always be "webbrowser-app"), it
> should be moved to src/app/webcontainer/webapp-container.cpp. The second
> parameter to BrowserApplication::initialize() would then become "appId"
> instead of "defaultAppId".

well actually no, my view of things (and it is reflected by the way I did this)
is that when you have a single click, you want to implicitly share those
between the apps. It is based on some use cases that required that semantics,


-- 
https://code.launchpad.net/~abreu-alexandre/webbrowser-app/fix-application-name-setup/+merge/293658
Your team Ubuntu Phablet Team is subscribed to branch lp:webbrowser-app.