The browser launched by unity-webapps-runner should be configurable

Bug #1036726 reported by Jorge Castro
136
This bug affects 29 people
Affects Status Importance Assigned to Milestone
WebApps: libunity-webapps
Won't Fix
Wishlist
Unassigned
unity-webapps-qml
New
Wishlist
Unassigned

Bug Description

It would be nice if we could explicitly launch a webapp with a supported browser (chromium or firefox) instead of just assuming the default browser supports webapps.

This would allow people who use Chrome and other non-webapp-supported browsers as their default browser but still use Firefox/Chromium for webapps

Jorge Castro (jorge)
visibility: private → public
Revision history for this message
Ken VanDine (ken-vandine) wrote :

I think we should add a heuristic for figuring out if the default browser is one supported and you have the right extensions installed and choose something different if needed.

For example if you have the firefox webapps extension installed and not the chromium extension, but chrome or chromium is your default browser, unity-webapps-runner should launch firefox instead of chrome because it can provide the optimal unity webapps experience.

Revision history for this message
dale f (manzanitalaceration) wrote :

Exactly, firefox is my default and preferred browser, but not for webapps. I prefer Chromium for webapps.

Maxim Ermilov (zaspire)
affects: webapps-applications → libunity-webapps
David King (amigadave)
Changed in libunity-webapps:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
Maxim Kuznetsov (mackuzzz) wrote :

#1 It would be great.

Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :

Thank you for your comment, definitely something to consider.

Revision history for this message
Tom Haddon (mthaddon) wrote :

Also, note that if you use two browsers (for example, one for work and one for personal use) and install a webapp from your non-default browser it will still launch in your default browser. This is pretty confusing, and means the webapp doesn't inherit any of the settings you have for that application in that browser.

Revision history for this message
Tobias Bradtke (webwurst) wrote :

Maybe you could add a commandline-option to select a browser:
$ unity-webapps-runner -b 'chromium-browser' -n 'R01haWwA' -d 'mail.google.com' %u

So we could edit our desktop-files as a first step before more magic or options will be implemented later.

Revision history for this message
karl (karl-sebastian-liebich) wrote :

+1 - because changing the .desktop file does not help for it is overwritten somehow back to former state when using "add event" for GoogleCalendar for instance

Revision history for this message
Brandon Mayes (bdmayes) wrote :

I would love to see this as well. I typically use Chrome for most of my browsing but use Firefox for certain things. For example, I recently started a new job and they use many Google services (gmail, calendar, drive, etc.). My idea was to use chrome for my own personal Google account, and then use Firefox for my work account.

Unfortunately, if I use the web app feature when Firefox prompts me, then it launches Chrome when I click on the launcher icon. I would prefer to be able to associate this with my "work" account info (which means I need to configure it to point to Firefox instead of Chrome) so I can get native gmail/calendar notifications in Unity which are associated with my work account.

Hope you can make this happen. Thanks!

Revision history for this message
Robert Bruce Park (robru) wrote :

My understanding at this point is that we are working towards running webapps in an isolated webapps container, ie, neither firefox nor chromium, but instead our own webbrowser-app (which is a very lightweight webkit browser spawned from the Ubuntu Touch project).

The goal of doing it this way is that it will allow us to drop a large amount of hard-to-maintain code from unity-firefox-extension and unity-chromium-extension, and provide for a smoother overall experience (eg, chromeless windows for webapps to run in, better/easier integration with the Unity launcher/switcher/etc).

Changed in libunity-webapps:
status: Confirmed → Won't Fix
Revision history for this message
David Barth (dbarth) wrote : Re: [Bug 1036726] Re: The browser launched by unity-webapps-runner should be configurable

Le 18/10/2013 20:24, Robert Bruce Park a écrit :
> My understanding at this point is that we are working towards running
> webapps in an isolated webapps container, ie, neither firefox nor
> chromium, but instead our own webbrowser-app (which is a very
> lightweight webkit browser spawned from the Ubuntu Touch project).
>
> The goal of doing it this way is that it will allow us to drop a large
> amount of hard-to-maintain code from unity-firefox-extension and unity-
> chromium-extension, and provide for a smoother overall experience (eg,
> chromeless windows for webapps to run in, better/easier integration with
> the Unity launcher/switcher/etc).
This is indeed the plan.

Yet, I understand the use-case and the solution may be in how we bind
online accounts to dedicated webapp container instances.

If you enable the new container mode, you will get a dedicated browser
instance per webapp. Each instance has its own set of
cookie/password/history databases. So you should be able to read
professional emails when logged as user A, and still be able to read
news (or other emails) when logged as user B, without having to use 2 or
3 different browsers.

To enable the new container mode, do:

apt-get install webbrowser-app
touch ~/.local/share/unity-webapps/enable-webapp-container

You will have to re-create your .desktop shortcuts, as the new mode
requires an extra property in it (the StartupWMClass paramater).

Then, each webapp will run in its own browser container.

To get back to using the default browser, just remove the configuration
file.

David

Revision history for this message
TomasHnyk (sup) wrote :

David Barth: Is this supposed to work with 13.10? I tried it and all I get is an empty window (see screenshot).

Revision history for this message
TomasHnyk (sup) wrote :

This screenshot.

Revision history for this message
David Barth (dbarth) wrote :

Le 22/10/2013 14:51, TomasHnyk a écrit :
> David Barth: Is this supposed to work with 13.10? I tried it and all I
> get is an empty window (see screenshot).
>
Which webapp (ie URL) is giving you that blank window? Can you paste
your .desktop file (look into ~/.local/share/applications)

David

Revision history for this message
TomasHnyk (sup) wrote :

It was for Facebook, it was solved by installing chromium-browser (I cannot get that page anymore). This might have been an issue on my part as I was using chromium for webbaps in 13.04 and the .desktop file might have stayed (I reinstalled 13.10 but kept my /home). But I do not use the feature anymore, it was buggy - clicking on it in the launcher would spawn a new window and I did not find a way to use extensions with the webbapp.

I actually thinkg this is a big usability drawback with the lightweight browser idea. Webbapps are for very popular sites that have site specific extensions to them, which you won't be able to run in the webbapp container (or will you)? In my case, I wanted to use http://socialfixer.com/ as it makes Facebook usable.

Revision history for this message
Robert Bruce Park (robru) wrote :

Our implementation of webapps depends heavily on injecting javascript code into websites in order for them to integrate their DOM into our launcher/messaging menu/notifications/etc. Although there might not be any user-facing interface to enable third party extensions like the one you mention, there's no technical reason that it couldn't inject that stuff while also injecting it's own webapp magic. Might just need to play with the source a bit, I dunno.

Revision history for this message
TomasHnyk (sup) wrote :

Hm, but I guess for social reasons, this will not work as for every extension that is currently functioning, somebody would need to adapt it to Ubuntu's webbapp and I doubt anybody would bother. The webapps provide too little of a benefit to justify the effort. But then I guess the number of people wanting to run such extensions is too small to justify your effort to implement something that would enable users to use extensions easily.

I run Facebook in a browser now. It works reasonably well, the only drawback is that it opens all its links in that browser, which is not my preffered :-(.

Revision history for this message
valmar (valmar-lp) wrote :

Dear David,

   I like the idea and tried in on two apps: Gmail and Google Plus. When I open the Gmail webapps, the webbrowser app comes in with the gmail login screen. When I try to login, by entering login name and password, a tab *in my main broswer* opens, asking again for the password. If I type it, I log in to Gmail *in my broswer*. Nothing happens in the webbrowser app.

With Google Plus, I just get a blank screen.

I am reporting these problems hoping to make everything work because I really like the idea of webapps in the webbrowser app!

   Valerio

Revision history for this message
Robert Bruce Park (robru) wrote :

Valmar, please report a new bug describing those issues. Those issues are not related to this bug, which is closed.

Revision history for this message
valmar (valmar-lp) wrote :

Ok, sorry!

Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :

Valmar: this is something that we are working on, the issue is that we try to make sure that the webapp in itself is contained (cannot browser to e.g. facebook when in the calendar webapp). This is done (lacking a better mechanism) at the url filtering level and based on accepted patterns for url browser within a given webapp. This works for most web applications, but google is a special player in that it uses a centralized auth mechanism that makes it hard to determine exactly what the containment pattern should be.

We are working on a better solution.

One way to mitigate the issue is to expand the list of allowed urls in the manifest.json files for each webapp (e.g. for gmail in /usr/share/unity-webapps/userscripts/unity-webapps-gmail) add:

"https://accounts.google.*/*", "https://www.google.com/a/*"

to the list urls found in the "includes" property.

Revision history for this message
valmar (valmar-lp) wrote :

Alexandre: this worked, thank you. By the way, is the integration with the messaging menu for Gmail supposed to work already?

Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :

Valmar: yes, there are a few bugs, that I am working on and that will be backported, see

https://bugs.launchpad.net/unity-webapps-qml/+bugs

Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :
Revision history for this message
valmar (valmar-lp) wrote :

Alexandre: This is in addition to the change of 'includes' above, right?

PS: I opened another bug report about this, as instructed by Bruce. You might want to close it on mark it as a duplicate of this one...

Thank you for your help

Revision history for this message
valmar (valmar-lp) wrote :

Alexandre: I tried the patches and they work beautifully. Just one thing: the window is a "mobile" style one (i.e. no scrollbars and tap(click)-to-zoom. This is not optimal on a desktop. However, I think this has more to do with the webbrowser-app than you and will probably go away when webbrowser-app can change behavior depending on whether it is on desktop or touch screen.... (Come, convergence, come!!!)

Revision history for this message
Alexandre Abreu (abreu-alexandre) wrote :

Valmar: 100% agree, we are aware of that and will be working on a more "desktopified" version starting now,
thank you for your feedback,

Revision history for this message
valmar (valmar-lp) wrote :

Alexande: One more thing. I am trying the feedly webapp, whose login windows comes in a pop up. I get a warning saying something like: "Disable popup blocker and retry". Do you know if there is a way around this?

Please count on me for help on debugging and testing the webapps. If necessary, contact me privately.

 Valerio

Changed in unity-webapps-qml:
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.