I just discovered that the whole tool to create webapps is just working incorrectly.

If I create a new webapp now, instead of opening a new window without tab and address bar, it opens a regular chromium window with:

- empty tab
- a tab of a saved webapp
- whole address bar with extensions

So it doesn't differ now from just creating a new window and the whole point of "installing" webapp is gone.

Deleted: Screenshot_20181019_090408.jpg 36.1 KB

	Screenshot_20181019_090408.jpg 36.1 KB View Download

The same issue happens on Chrome and on Windows 10 now. Webapp just starts another window of Chrome (if Chrome is already opened, if not, it opens main window with a tab of that app), so navigating between windows is not easy anymore (as windows are grouped as the same application Chrome or Chromium, before webapp had own icon and launched as if it was a separate app).

So basically the whole feature of installing webapps is broken across Chrome/Chromium on any system.

Same here, I have a dark webapp on a dark desktop and a light useless bar in between.

Deleted: Screenshot from 2018-10-20 12-42-28.png 44.5 KB

	Screenshot from 2018-10-20 12-42-28.png 44.5 KB View Download

Tried testing the issue on chrome reported version# 70.0.3538.67 using Ubuntu 14.04 with steps mentioned below:
1) Launched chrome reported version and selected "Use a system title bar and borders"
2) Installed(https://chrome.google.com/webstore/detail/asana/khnpeclbnipcdacdkhejifenadikeghk?utm_source=chrome-ntp-icon) from Chrome Web Store
3) Clicked on extension icon, able to see new tab opened on same window
Observations:
=> Also tested without selecting "Use a system title bar and borders", clicked on extension icon, able to see new tab opened on same window
=> Tested the issue on Windows-10, Installed(https://chrome.google.com/webstore/detail/asana/khnpeclbnipcdacdkhejifenadikeghk?utm_source=chrome-ntp-icon) and clicked on extension icon, able to see new tab opened on same window

@Reporter: Please find the attached screencsat for your reference and let us know if we missed anything in reproducing the issue, provide your feedback on it which help in further triaging it. If possible could you please provide screencast of the issue which help in better understanding.

Thanks!

Deleted: 896584.ogv 3.2 MB

	896584.ogv 3.2 MB View Download

viswa.karala@chromium.org you are missing the whole point of the bug.

It's not about being able to turn on/off system titlebar.

It's about webapps installed from Chrome/Chromium! So basically, a webapp was searchable by system menu and started a separate window with that site and it was also shown as an independent program with, independent icon, so we could pin it to the taskbar and launch it INDEPENDENTLY from the browser's session. This is so much better than having multiple apps in tabs of a one window. So in a nutshell, Chrome/Chromium allowed us to create SSB's (Single Site Browsers) and now that feature is completely broken!

There are numbers of issues that came with the update.


1. Webapp is not respecting setting of "use system titlebar and frames"

Previously, we could change ANY SITE to a webapp and such webapp was respecting the general settings. After the update, those webapps stopped doing that - they use chrome titlebar and we cannot change it. In certain setups that's just not good and is producing a useless bar that stands out. But that's not all.

2. Creating SSB's is not working anymore.

It turned out that this update removed the option to create freely webapps. The feature to install any site is just gone from the menu. Those webapps who were previously installed are still there and have this browser's titlebar despite general browser settings.

So when I uninstalled Asana webapp (to test it), I couldn't install it again. All I can do is to "create shortcut" which does exactly that, creates a shortcut, nothing more. Before I could "install" the site. So in the end result, if a browser is opened and I click a shortcut, it opens a new window with an empty tab and site that was "shortcutted", which is presented in the screen above. Such new window has the same icon as Chrome/Chromium so it's not easily distinguishable and switching between browser and such other browser window is not good for the workflow.

3. SSB's that gave us full options to create any webapps was replaced by PWA's (Progressive Web Apps). So previously we could open a PWA site and install it as SSB (along with any site), now we can do the same but only for CHOSEN PWA's. Some simply don't have that option, for example, google maps aren't installable that way, although it is considered a PWA.

Installed PWA is behaving like shown above: it is a single window with a browser (non-system) titlebar. So basically old SSB's tuned into those new PWA's.

I found about those PWA's through this article:

https://www.ghacks.net/2018/10/18/how-to-install-progressive-web-apps-in-google-chrome/

If only it worked for all PWA's but no, the choice is very limited.


So this is a disaster. We had previously fully featured, perfectly behaving SSB feature that now is gone and replaced by some damaged, incredibly limited version. For me, this is a clear regression.

I have to use other third-party programs to have SSBs, but they don't work as well as Chrome/Chromium did.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding UI>Browser>WebAppInstalls component to it and CC'ing: alancutter@chromium.org, mgiuca@chromium.org to provide inputs on this issue.

Thanks!

Note: The windowed display is still available via chrome://apps, right click icon, Open as window.

It sounds like the two issues raised here are:

1. Windowed browser apps no longer support Linux window managers that want to hide the title bar.
This is largely a result of ramping up the security UI for PWA windows so that permission icons (like geolocation) and the site's origin can be shown to the user in a non-spoofable way. Essentially the title bar has taken up the security UI role of the location bar and app menu.

2. Creating a windowed shortcut app is now hard to discover.

Thanks. That gives some answers but I would also clarify:

1. The issue is not limited to Linux or Chromium. The same is with Chrome and Windows - so this is a general situation.

2. Having options through titlebar is a bad solution as it limits options and clashes with the browser's settings (forced browser drawn titlebar despite settings). In a way, it's OK for users to discover it (3 dot menu on the titlebar), but is not working when we want to use "use system titlebar and frames".
So there should be UI installed app settings preferably with easy discoverable apps.

The good thing about having SSBs or PWAs is that they are simplified and lack of typical browser elements like address bar and so on, so ability to have system titlebar (which can be hidden or stripped of my system in a maximized state) is providing further simplification and integration with a system. That is not universally helpful for all, but for some users like me, this is an important part of the webapp experience and a good usage of screen real estate (maximized view/access area).

3. Apps being not discoverable is not the only thing what is a problem here.

Checking my chrome://apps I can see for example asana.com on the list and yet it doesn't work as an app, because it is a shortcut. So it adds another confusion or is a bug.

As mentioned before, I uninstalled Asana app to test it and then wanted to install again but found out it is not possible anymore, I can only "add a shortcut" and then asana shows on the apps list but is not behaving anymore like a SSB or PWA, so the app list is misleading or working incorrectly. Shortcuts are not apps.


So the question is: is this security new measure forcing Chrome to limit the choice for PWA's or is it a matter of having a place for security options? If the latter, then there is no reason to limit our choices of webapps.

At the moment we went from the total freedom (100% sites could be changed into SSB's) to a fraction of a percent (only chosen PWA's can be installed, not even all of them) and that's clearly a massive downgrade. Irritably showed in media as a new, cool feature... yeah...

Will Chromium/Chrome do something about it or just close this chapter and leave others to create clunky SSB's solutions who use Chrome/Chromium as an engine anyway?

Currently, it's not even ideal for clear PWA's (limited choice, sub-optimal titlebar and settings placement, bad discoverable app list and lack of app management settings).

I have this problem in Xubuntu 18.04 too

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/70.0.3538.67 Chrome/70.0.3538.67 Safari/537.36

Steps
1. Set Chromium/Chrome to use "System titlebar and borders"
2. Go to chrome://apps
3. Set a web-app to "Open as a window" (i.e. Chrome Web Store)
4. Launch the previously marked web-app
4.1 From chrome://apps, just click the app
4.2 From terminal using the --app-id flag: chromium-browser --app-id={id}

Results
1. It opens a window with borders created by Chrome/Chromium with colors from my GTK theme (i.e. Adwaita) instead of the Window Manager theme (i.e. Numix).

This clashes with the Window Manager theme applied to every other window in the desktop enviroment. Didn't happen before in 69.0.3497.81
I also posted this on AskUbuntu https://askubuntu.com/questions/1086767

I've noticed three related issues around showing the title bar with permission icons vs respecting the window manager's title bar.

1. This issue where Linux window managers are quite diverse, can hide the title bar completely and don't necessarily align with the GTK theme settings; we fail to present like a native application.
2. Issue 878270 where in tablet mode on ChromeOS the title bar is removed and PWAs are unable to display the app menu or permission icons.
3. Issue 896085 where on Windows 10 with high contrast mode is enabled the system title bar is displayed and PWAs are unable to display the app menu or permission icons.

Finding a cross platform solution for satisfying our security UI requirements without a title bar would solve all three of these issues.

For issue 1, looks like Chromiums tries to use the background color from manifest.json for the titlebar text.

In the screenshot:
- Instagram: #FFFFFF White bg color -> White titlebar text
- Maps: #FFFFFF White bg color -> White titlebar text
- Twitter: - No bg color -> Default gtk titlebar text
- Web Flap: #4EC0CA Cyan bg color -> Cyan titlebar text.
- NASA code: #212121 Dark grey bg color -> White titlebar text

I would expect Instagram, Web Flap and NASA to respect the manifest colors but for some reason NASA fails and defaults to white text.

Should i open a different bug for this?

Deleted: pwa.png 1.0 MB

	pwa.png 1.0 MB View Download

Not sure how viable idea that is, but many SSB programs that I tried lately are using side panels. If a titlebar is producing so many friction points, let's go back to the old titlebar but have a sidebar that pop-ups when some security info needs our attention, but this sidebar should be also possible to hide completely.

So this comes along with an easily accessible and discoverable app management site where we can access settings of each app.

SSB programs often create a problem by not having such additional setting place so once you hide side panel, you can't get it back.

So to sum up:

1. Let's have all needed settings of an app in a sidebar (possible to hide), so on first launch such sidebar would be on.
2. Let's have an easy discoverable app management site with settings to each app so we can bring back sidebar.

Alternatively, the sidebar should be possible to restore from context menu if you insist on having barren chrome://apps site.

Also, thanks to  nervlove...@gmail.com, I know how to turn shortcuts into SSB now - this is a completely convoluted way and I would never figure it on my own:

a) create a shortcut of the chosen site
b) go to chrome://apps (that is not discoverable on its own)
c) right click on a shortcut app and mark "Open in a single window" - this transforms shortcut into the usual SSB but with that problematic titlebar.

That method was described on comment #10. The access to chrome://apps it's always present in the bookmarks bar when you open a new tab.

But i also noted (as pointed in #11) that the method for creating PWA/SSB was changed several versions ago:

BEFORE: 3 dot menu -> More Tools -> Create Shortcut -> Create
this will add a bookmark in chrome://apps and a shortcut in your app launcher that uses the --app flag to launch the site. The --app flag means that it always launch as a SSB.

NOW: 3 dot menu -> More Tools -> Create Shortcut -> Create
This also adds a bookmark in chrome://apps and a shortcut in your app launcher, but now every PWA/SSB uses the --app-id flag. This means that every site it's packed into a WebExtension, assigned an {app-id} an added as a shortcut to chrome://apps. Now it's the user who has to mark every app to "Open as a window" manually if they want.

The --app flag was modified and now opens every url in a tab in the browser. You can test this launching this from a terminal:
chromium-browser --app https://chrome.google.com/webstore/category/extensions

- - -

Regarding the window titlebar, i think the reasons in comment #11 are good. Some sites are shady and having that information in front makes users less prone to spoofing and fishing, etc.

The code that assign the CSD titlebar colors can improve to use colors from the manifest.json, that would pass the responsibility to the sites/apps and make them the look native and branded, example:
- Default -> Black text / white background
- Facebook -> Titlebar text: white / titlebar background: blue
- Whatsapp web -> Titlebar text: white / titlebar background: green
- Gmail -> Titlebar text: white / titlebar background: red
- etc.

Well, for some color is the problem, for others, the whole non-system titlebar is the issue. If there is no non-system titlebar (like before) there was no color issue... just saying ;).

However, to be exact, some will want to use browser generated titlebar (CSD - Client Side Decoration) and then the color problem will pop-up anyway.

For me, the non-system titlebar is alien looking anyway (so different from system titlebar: wrong color, wrong borders, wrong buttons, wrong side of the buttons, wrong shape) so the color is secondary. Chrome's CSD isn't using system buttons or style anyway so it's not a good option on Linux unless you are not bothered by its inconsistent look with the rest of the system.

The thing is:

Security needs settings to be presented somewhere so it forces CSD, but it clashes with general browser setting that may be set differently, so in the end, this creates inconsistency in Chrome/Chromium anyway.

This is a multilayered issue. As mentioned above, presenting options in hideable sidepanel could solve that, but I suspect this is a new UI element that doesn't exist in Chromium/Chrome and it won't be so easily introduced but should be considered anyway. Or maybe temporary accessible browser elements that are usually hidden in SSBs (like address bar with extension's icons and access to menu, info and other settings).

Some browser element must take that role because otherwise there is no place to put it anywhere.

Some extensions can overlay status icons on a site and that is also an interesting way of presenting info and accessing settings.

Here is an example (check right bottom corner):

Deleted: Screenshot-2018-10-25-23-08-03.png 155 KB

	Screenshot-2018-10-25-23-08-03.png 155 KB View Download

Deleted: Screenshot_20181025_230839.jpg 95.3 KB

	Screenshot_20181025_230839.jpg 95.3 KB View Download

#15: yes, that's a separate issue. Please open a new bug about it. Also if you want the manifest's theme color to apply to the title bar, you need to change the Theme to Classic in chrome://settings.

#17:

> The --app flag was modified and now opens every url in a tab in the browser. You can test this launching this from a terminal:
chromium-browser --app https://chrome.google.com/webstore/category/extensions

That looks like an unintentional change. Would you mind opening a new bug about it as well?

#15,#19: Bug exists for this issue:  https://crbug.com/896146 

The recent change spans new issues all the time...

I was able to add new SSB (asana.com) via add shortcut->open as a window, but when pinned to a taskbar (icon taskbar in Plasma) it launches Chrome window with Chrome icon, although app was created in Chromium. When I launch SSB from desktop file, it launchers correctly with its own window and icon, but launched from a pinned taskbar it's just another Chrome window, without own icon so it's grouped with other Chrome windows which destroy the points of making SSB.

Old SSB works still OK, so something seems to be missing in the latest iteration of SSBs.

This bug is not the one discussed here but it's related anyway. So more of the weird and unintentional stuff is happening because of the recent change. The more important is to find another solution for it. The current state is a mess (it all worked perfectly before).

#22: Is this still Linux? Can you elaborate on how the pinned taskbar shortcut was created? Screenshots would help a lot also.

Yes, it's Linux. I tested it furthermore and it turned out that when I was experimenting, I also created Asana app in Chrome (so I had app in Chrome and Chromium), so I deleted/uninstalled it, Chromium one disappeared too and then I created it anew with Chromium only and now it behaves correctly. Launched from a taskbar maintains separate window and icon and is not using Chrome.

I guess it's only a thing of Chrome and Chromium bleeding into each other which is an entirely different thing.

So all in all, it's OK, webapp is created and behaves correctly aside having non-system titlebar.

Sorry for the confusion.

#21: Added same screenshot as my previous comment for more details.

#20: Nevermind, the flag it's --app={url} and not --app {url}. It works.

Thanks for following up.

I'm still not pleased with how out of place PWAs look when the GTK theme is selected and would like to move back to using the real native system titlebar, possibly by always showing the location bar for origin + permission icons in GTK mode.

When I switched to Gtk theme (previously classic theme) situation improves slightly as the titlebar uses Gtk theme which we can choose. The only drawback now is the lack of the ability to move buttons from right to left and system is not able to strip down the titlebar in maximized mode, so this titlebar is always present whether it's needed or not.

I noticed that after latest update some new options showed up on the titlebar. This is strange. I now must allow for outgoing links on such site? Why? This is no different then any normal site and nobody is policing those sites, it's up to me to know what I click, so I don't understand why Chromium/Chrome feels the need to add this extra security layer.

Another problem showed up. After update icons are missing. SSBs use separate windows (so they are not grouped) which is good but there are no ways to differentiate between them. Additionally, they always use Chrome icon, although SSB is created in chromium and has chromium path:

/usr/bin/chromium --profile-directory=Default --app-id=egeogmlicipflbahncmbgckiblcmgnoe

Here are the screenshots:

Deleted: Screenshot-2018-10-30-09-54-13.png 633 KB

	Screenshot-2018-10-30-09-54-13.png 633 KB View Download

Deleted: Screenshot_20181030_095102.jpg 111 KB

	Screenshot_20181030_095102.jpg 111 KB View Download

> I now must allow for outgoing links on such site?

What do you mean?

#27

>"(...) The only drawback now is the lack of the ability to move buttons from right to left (...)"

This is hit or miss. It works for me in xfwm using PWA with either classic or gtk theme but doesn't work in my VM with Ubuntu Mate 18.04

> "(...) and system is not able to strip down the titlebar in maximized mode, so this titlebar is always present whether it's needed or not."

This is because for PWA (--app-id flag) chrome always uses CSD and not your Window Manager borders. I have the same problem when maximizing windows in xfce, the CSD titlebar in chrome it's always visible while my window manager setting is "Hide titlebar when maximized".

> "(...) After update icons are missing. SSBs use separate windows (so they are not grouped) which is good but there are no ways to differentiate between them. Additionally, they always use Chrome icon, although SSB is created in chromium and has chromium path:"

This could be a problem in how KDE taskbar works, for me PWA and sites opened with the --app or --app-id flags always show icons, it also works with Plank dock in xfce and my vm with Ubuntu Mate 18.04.


In the screenshot (Chromium-WindowManager-CSD.png):
- Chromium with classic theme enabled
- UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/70.0.3538.77 Chrome/70.0.3538.77 Safari/537.36
- DE: XFCE 4.12.3 / WM: xfwm 4.12.4
- Windows buttons positioned left, right and applied to CSD window and normal windows.
- Top taskbar shows icons for PWA (StackEdit and Pokedex.org) and sites opened with --app flag (Slack, Outlook)
- Bottom: Plank dock shows icons for PWA (StackEdit and Pokedex.org) and sites opened with --app flag (Slack, Outlook)

In the screenshot (VM-mate-18.04):
- Chromium with gtk theme enabled
- UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/70.0.3538.77 Chrome/70.0.3538.77 Safari/537.36
- DE: Mate 1.20.1 / WM: marco 1.20.1
- Windows buttons positioned left not applied to PWA.
- Bottom: taskbar shows icons for PWA (Alsana, NASA, Maps, Instagram)

Deleted: Chromium-WindowManager-CSD.png 458 KB

	Chromium-WindowManager-CSD.png 458 KB View Download

Deleted: VM-mate18.04-Screenshot_2018-10-31_11-54-45.png 744 KB

	VM-mate18.04-Screenshot_2018-10-31_11-54-45.png 744 KB View Download

#28, just look at the screenshot above, there is an icon in titlebar that looks like an eye or something. If you click it, you will be redirected to permission page about outgoing links.

I can understand that you need a permissions system if you install actual extensions, but an SSB is just a site, nothing more, nothing less. Even if it's PWA, it's a site you can open in any browser and having special permissions for those is weird. In theory, they can be set per site basis, but enforcing them just because a site was changed to a windowed version? Hmm... This is controversial. That's just my two cents. It's not an issue we are discussing here thou.

#29, thanks, didn't know that the buttons do move sometimes. It looks like in xfce it works, in other DEs it doesn't, there have to be some settings that xfwm is changing that chrome is recognizing. The question is where and can we do it manually?

Focusing again on that CSD titlebar that is the center of this thread, what would work, given current additional access to security and other settings:

1. Have easily discoverable app center with SETTINGS for each site/app
2. When creating "a shortcut" we should already be presented with the option to open a site in single window mode (and eventuall info that we can change that later in app settings on app center/management page)
3. When a new permission or other settings must be set and wants our attention, some kind of pop-up with that info should show up and there should be a way to: dismiss forever, remind later, allow, go to the settings (which would redirect to the app's site and give site settings - this would teach people that those settings are available there at any time and because of that, we wouldn't have a need to have enforced settings access on a CSD titlebar.
4. App settings need a setting for each app: "use system titlebar and frame". So by default, a new SSB or PWA app would have this own CSD but we could disable it manually. This wouldn't be a big deal if necessary security messages were able to pop up and direct to the settings if needed.

This would ensure that all the features you want will still be there, accessible at any times, pointing and teaching users where you can find them, so the enforced CSD titlebar wouldn't be needed. Enforced CSD just creates too much friction in certain setups and problems. On windows this looks good because the option to use the system titlebar works now and it also has the access to the settings you want. On Linux you can't do the same since there are to many WM's and they usually don't have proper API for such options. Making those options available and easy discoverable elsewhere will nullify the need to enforce CSD's which is not a good idea.

Re: the eye-looking icon, that is a bug that comes up when changing themes while the window is opened. If you close the window and open in again it should go away. It was recently fixed; see  Issue 878639 .

1. This isn't tied to the main browser settings because the installed apps are supposed to be more or less independent from the browser (they should not be tied to browser settings).

2. #30 Yeah, it might be reasonable to have some separate configuration to customize the look of these apps once installed. However, this is currently outside of our means (we do not have a lot of resources to dedicate to Linux, and other platforms are much more in the camp of giving developers full control over the look and feel of their windows).

While I think this would be good, I'm closing this as infeasible since we're unlikely to add a configuration UI just to let users control how apps work on Linux.