(In reply to Yauhen Shulitski from comment #0)
> Hi,
> 
> I have just updated to fedora 28 (which means gnome 3.28). I have noticed
> that the default behaviour of Epiphany in Application mode has changed. When
> I click a link, instead of opening it in the default browser, it opens it in
> a new tab. "Open in browser" button appears in the head bar. Also New tab
> button is available in Application mode. The application mode no longer
> feels like "an application mode". It feels more like a regular browser.

Yeah, but it's required to be able to log in to several websites.

I'm getting really, really disillusioned with web apps. I no longer use them myself, they are incompatible with our primary distribution mechanism (flatpak), and I don't see any path towards ever getting these working well.

> Is there a way (a config option for example) to make it work as it used to?
> I wasn't able to find any information about that change.

I don't think there is. There should be a button in the headerbar to open in the default browser, though.

I have HipChat as a web application. It works more stable like this than electron version.

Keeping web applications use case in mind, I think it might be "better" to have "Open in new tab" button instead. However, it is not clear when it should disappear. Confusing indeed :/

With the new update clicking on a link opens it in the same window and there is no way to go back to your "application" unless you click "Open in browser" tab. I think it would be nice to at least enable Back button clicking on which redirects you to the application view

It does become more difficult when you have 5-6 web apps open and you click on something you want to read and it ends up in new tabs in the web apps.

It's cluttered and confusing. I think that most users would expect the main browser to herd all of the links that they want to read.

The only thing that I would think of that is different is whether Web can (or should) steal focus when a link is clicked in a web app. In other apps, like Evolution, Web opens the link in the background if it is the default web browser, which might startle a user who was expecting something to happen right away.

If, say, Firefox is the default web browser in GNOME, it grabs the focus and opens the page when you click on a link in Evolution, so from that, I'm left to conclude that applications *can* take focus regardless of what GNOME's window manager wants to do, but Web simply doesn't, which may be unexpected.

I've found myself (out of force of habit) clicking on links in external applications several times and thinking "Why isn't this doing anything?" and then switching to Web and finding several identical tabs that opened in the background.

Web stealing focus would make sense in the context of GNOME Shell's workflow because the user can quickly get back to their web app. 

My setup is a little different. Dash to Dock on the left of the shell and Minimize, Maximize, and Close buttons on the window title. But I think that taking focus would work okay in either configuration. 

So I would go further and summarize the behavior I'd consider ideal as:

"Web should open links from external programs by taking focus away from the external program. Web should also treat web apps as an external program."

I discussed this with Carlos Garcia a couple days ago. Since we've had several complaints about the behavior changes in bug #788845, and I haven't seen any comments from Gustavo, let's revert that series of commits for now. It's going to break Mattermost and other websites that do authentication on separate domains, so I'll do the revert only on master, not for 3.28. Another solution will need to be found. Carlos Garcia has been suggesting just adding a whitelist in preferences dialog, and did some work last year to make the preferences dialog usable in web apps, so that was possibly the first step.

I decided to keep https://gitlab.gnome.org/GNOME/epiphany/commit/1b8facf14d83991e6206d5629a166b8feb5c4469 since we separately agreed to allow tabs in app mode, if the user wants to use them.

The following fixes have been pushed:
8976ca0 Revert "Track the currently committed address"
40209ab Revert "application mode: track origins related to the application"
f331471 Revert "application-mode: improve detection of redirects to uris that are part of the app"
803b118 Revert "application mode: add button to open in default browser to non-app uris"
2044dc8 Revert "application mode: when opening a tab on the default browser, close it"

Created attachment 372455 [details] [review]
Revert "Track the currently committed address"

This reverts commit 34216ae096a296e29c5176a704f076434214d1ed.

Created attachment 372456 [details] [review]
Revert "application mode: track origins related to the application"

This reverts commit 57c863c1680285c6af41a9b75a67c5d6dae58b73.

Created attachment 372457 [details] [review]
Revert "application-mode: improve detection of redirects to uris that are part of the app"

This reverts commit f0e4daa860f684bb950c8dbcbc830c952e314924.

Created attachment 372458 [details] [review]
Revert "application mode: add button to open in default browser to non-app uris"

This reverts commit 0c3e4b26ffcb4d49ba7bbbe186f2ea314df5e449.

Created attachment 372459 [details] [review]
Revert "application mode: when opening a tab on the default browser, close it"

This reverts commit 26bb4848639e1c0ac45fdba8356308d5a347e697.

*** Bug 796431 has been marked as a duplicate of this bug. ***

Thanks Michael! Will it be a part of the Epiphany Technology preview? Looking for an easy way to install it.. :)

The problem is web apps don't work in Epiphany Technology Preview, so there would be no way to test using it. You'd have to build it yourself. Feedback much appreciated, since I know this is going to break websites we care about (e.g. Mattermost).

It is absolutely different problem, but I tried to build it myself and was able to start it, however I have missing icons and fonts. I followed instructions on this page https://wiki.gnome.org/Apps/Web/Development and used buildstream. Do you know by chance more detailed installation guide?

Honestly, buildstream is a real pain. It's the successor to jhbuild, but I'm not having much luck with it. It's expected for system fonts to be unavailable inside the sandbox, but it's not really a big deal for fonts to look different. Icons should be present, though. That will require some debugging.

Our developer experience is in an absolutely terrible state right now. I can't recommend this or put it on a wiki page, but I'm currently using a local jhbuild moduleset to be productive:


<?xml version="1.0"?>
<!DOCTYPE moduleset SYSTEM "moduleset.dtd">
<?xml-stylesheet type="text/xsl" href="moduleset.xsl"?>
<moduleset>

  <repository type="git" name="git.gnome.org"
      href="https://git.gnome.org/browse/"/>
  <repository type="git" name="gitlab.gnome.org"
      href="https://gitlab.gnome.org/"/>
  <repository type="git" name="git.webkit.org"
      href="git://git.webkit.org/"/>

  <autotools id="gtk+-3" autogenargs="--enable-x11-backend --enable-wayland-backend">
    <branch repo="gitlab.gnome.org" module="GNOME/gtk.git" revision="gtk-3-22"/>
  </autotools>

  <cmake id="WebKit" cmakeargs="-DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_X11_TARGET=OFF -DENABLE_PLUGIN_PROCESS_GTK2=OFF">
    <branch repo="git.webkit.org" module="WebKit.git"/>
    <dependencies>
      <dep package="gtk+-3"/>
    </dependencies>
  </cmake>

  <meson id="epiphany">
    <branch repo="git.gnome.org"/>
    <dependencies>
      <dep package="WebKit"/>
    </dependencies>
  </meson>

</moduleset>

Thanks! My experience with jhbuild was much better than with buildstream. Had to build also adwaita-icon-theme to fix some icons. Looks great so far (hipchat as webapp). I will keep testing.

Few things that I noticed:
 - I see that you decided to keep https://gitlab.gnome.org/GNOME/epiphany/commit/1b8facf14d83991e6206d5629a166b8feb5c4469 . How can a user enable using tabs in webapp mode? The New tab button is always inactive for me.

 - Also I have noticed that when you hover a link, the tooltip in the bottom-left corner has no background (see attached file).

 - When user does right click on link, there is an option "Open link in a new tab" which does nothing. I think it should open a link in default browser instead

(In reply to Yauhen Shulitski from comment #18)
> Thanks! My experience with jhbuild was much better than with buildstream.
> Had to build also adwaita-icon-theme to fix some icons. Looks great so far
> (hipchat as webapp). I will keep testing.
> 
> Few things that I noticed:
>  - I see that you decided to keep
> https://gitlab.gnome.org/GNOME/epiphany/commit/
> 1b8facf14d83991e6206d5629a166b8feb5c4469 . How can a user enable using tabs
> in webapp mode? The New tab button is always inactive for me.

Well you're not supposed to be able to create a new tab yourself, because there is no way to enter URLs, so you would only see the overview, which would be a pretty terrible experience. But I think you could either middle click or Ctrl+click on links. I didn't test this, does it not work?

>  - Also I have noticed that when you hover a link, the tooltip in the
> bottom-left corner has no background (see attached file).

This occurs always, or only in web app mode? Maybe something broke in GTK+....

>  - When user does right click on link, there is an option "Open link in a
> new tab" which does nothing. I think it should open a link in default
> browser instead

OK, I'm not going to spend any time making changes to web apps, so it sounds like I need to revert https://gitlab.gnome.org/GNOME/epiphany/commit/1b8facf14d83991e6206d5629a166b8feb5c4469 then, if it's broken. Do you agree?

Created attachment 372491 [details]
Missing background for urls

Created attachment 372492 [details]
Inactive new tab button

Sorry, forgot to attach the screenshot with missing background for urls.

> This occurs always, or only in web app mode? Maybe something broke in GTK+....
It occurs only in webapp mode (tested the same website in normal mode and background was there)

Regarding the new tab. I agree with you that it should be impossible to create a new tab in webapp mode. I think https://gitlab.gnome.org/GNOME/epiphany/commit/1b8facf14d83991e6206d5629a166b8feb5c4469 should be reverted too, as it just doesn't work.

Not exactly sure if this commit is enough, but I think it would be nice to have the following changes:
 - the "New tab" button from the title bar should be gone
 - "Open the link in a new tab" should be gone or open link in the default browser (as Ctrl + left click does)

(In reply to Yauhen Shulitski from comment #22)
> Sorry, forgot to attach the screenshot with missing background for urls.
> 
> > This occurs always, or only in web app mode? Maybe something broke in GTK+....
> It occurs only in webapp mode (tested the same website in normal mode and
> background was there)

That's weird, but I have a guess: it's probably caused by using libdazzle to load the themes, and the application ID not matching up. Could you report a new bug for this, please?

> Regarding the new tab. I agree with you that it should be impossible to
> create a new tab in webapp mode. I think
> https://gitlab.gnome.org/GNOME/epiphany/commit/
> 1b8facf14d83991e6206d5629a166b8feb5c4469 should be reverted too, as it just
> doesn't work.
> 
> Not exactly sure if this commit is enough, but I think it would be nice to
> have the following changes:
>  - the "New tab" button from the title bar should be gone
>  - "Open the link in a new tab" should be gone or open link in the default
> browser (as Ctrl + left click does)

OK, I believe reverting it will fix both. Please let me know if it doesn't.

The following fix has been pushed:
3ec0c0e Revert "application mode: allow tabs"

Created attachment 372493 [details] [review]
Revert "application mode: allow tabs"

This reverts commit 1b8facf14d83991e6206d5629a166b8feb5c4469.

Thanks! I can confirm that it resolves the issue

Just to add to this conversation, 3.28 finally made webapps useful for me. Previously, webapps were constantly broken when dealing with authentication or anything else that directed you off the main domain, since it opened in the default browser instead. 3.28 finally made this work, and I thought the "Open in Browser" button was intuitive and a good solution. Unfortunately, 3.28.2 which has removed the tabs has made webapps useless for me again.

I find webapps really useful for grouping. For example, we use Jira for project management at work. Having a Jira webapp is really great. It lets me organize my work into a single application. To me, when I made Jira a webapp, that is because Jira is not a website. It is an application I spend a lot of time in and want to be able to organize my work and keep it separate from other tasks. Having it be a separate launcher and a separate application in alt tab and the dock has really improved my workflow. Having tabs inside of my webapp was really beneficial and is necessary for most sites. When clicking on an external link, like a pull request which jumps to github, I found it useful that is opened as a new tab inside of my Jira webapp. Even though it took me to a different "website", to me, it is all part of the same "application". Losing this functionality is a huge loss to me.

I have even written a custom http handler to open links clicked on the desktop in my desired webapps rather than the default browser. This means when I receive an email about a Jira ticket, clicking on it takes me to my webapp, as I would expect it to. I wrote about this here:

https://blog.line72.net/2018/05/07/supporting-deep-links-in-linux-with-gnome-and-epiphany-web-apps/

I know there has always been a lot of ambiguity about how webapps should work and how epiphany should handle them. I found the 3.28 release finally made them robust and useful, and now I can't imagine living without them. I have already had to downgrade from 3.28.2 back to 3.28.1 since this ticket removed the tab feature :(

Thanks for your hard work. I hope you keep improving the webapps feature!

Hmm.. an interesting use case. Why do you need --application-mode flag in your desktop files? Won't it behave as you want if you just remove it?

The --application-mode sets the WM class so that I have a Jira application, not an Epiphany application. This allows gnome-shell to correctly group my Jira applications together and not lump them in with other webapps or Epiphany.

(In reply to Marcus Dillavou from comment #27)
> Just to add to this conversation, 3.28 finally made webapps useful for me.
> Previously, webapps were constantly broken when dealing with authentication
> or anything else that directed you off the main domain, since it opened in
> the default browser instead. 3.28 finally made this work, and I thought the
> "Open in Browser" button was intuitive and a good solution.

Yes, that's exactly why this change was made in the first place. It's a longstanding problem, though. We'll need to find a different solution that doesn't break these other established use-cases.

> Unfortunately,
> 3.28.2 which has removed the tabs has made webapps useless for me again.

Um, this was not intentional. I've specifically avoided backporting any of the above reverts to 3.28 so as to keep the 3.28 behavior unchanged.

I did push https://gitlab.gnome.org/GNOME/epiphany/commit/c56294dd46db69c94f8238dd47f568ca57bc51c0 earlier, but that should only prevent you from opening new empty tabs with Ctrl+T. That seemed like an obvious bug, since the overview isn't designed to work in web app mode. You should still be able to create new tabs from links you find on webpages (Ctrl+click, middle click, right click) in 3.28. Is that not working properly?

> I find webapps really useful for grouping. For example, we use Jira for
> project management at work. Having a Jira webapp is really great. It lets me
> organize my work into a single application. To me, when I made Jira a
> webapp, that is because Jira is not a website. It is an application I spend
> a lot of time in and want to be able to organize my work and keep it
> separate from other tasks. Having it be a separate launcher and a separate
> application in alt tab and the dock has really improved my workflow. Having
> tabs inside of my webapp was really beneficial and is necessary for most
> sites. When clicking on an external link, like a pull request which jumps to
> github, I found it useful that is opened as a new tab inside of my Jira
> webapp. Even though it took me to a different "website", to me, it is all
> part of the same "application". Losing this functionality is a huge loss to
> me.

Yes, that was the other motivation for this change: to make web apps more like "silos."

However, it's clear some users of the pre-3.28 web apps were disappointed by this change and want the opposite behavior. I don't have the answer. Maybe we should have two different modes. Not sure.

> I have even written a custom http handler to open links clicked on the
> desktop in my desired webapps rather than the default browser. This means
> when I receive an email about a Jira ticket, clicking on it takes me to my
> webapp, as I would expect it to. I wrote about this here:
> 
> https://blog.line72.net/2018/05/07/supporting-deep-links-in-linux-with-gnome-
> and-epiphany-web-apps/

Oh wow. :P

> I know there has always been a lot of ambiguity about how webapps should
> work and how epiphany should handle them. I found the 3.28 release finally
> made them robust and useful, and now I can't imagine living without them. I
> have already had to downgrade from 3.28.2 back to 3.28.1 since this ticket
> removed the tab feature :(

Again, you must be talking about https://gitlab.gnome.org/GNOME/epiphany/commit/c56294dd46db69c94f8238dd47f568ca57bc51c0, which was separate. 3.28.2 was released before any of the changes in this bug, and I have not backported any of them, so they will not be included in 3.28.3 either.

> Thanks for your hard work. I hope you keep improving the webapps feature!

This is the other problem, I don't use web apps myself, so I really don't know what we should do. My instinct is that it would be good to try to satisfy both camps of users, but I don't know how we can. This would be a great opportunity for the community to get involved in designing and implementing a solution. (There is also https://gitlab.gnome.org/GNOME/gnome-software/issues/390 to be considered.)

One strawman possibility: we could have "web apps" that work the same as web apps did before 3.28, and "silos" with the behavior of 3.28 web apps. I'm not keen on adding more complexity to the browser, but that would be one approach. Alternatively, the preferences dialog is now accessible for web apps and preferences are stored separately for each web app, so we could start adding preferences specific to web apps.

>> Unfortunately,
>> 3.28.2 which has removed the tabs has made webapps useless for me again.

> Um, this was not intentional. I've specifically avoided backporting any of the 
> above reverts to 3.28 so as to keep the 3.28 behavior unchanged.
> 
> I did push https://gitlab.gnome.org/GNOME/epiphany/commit/c56294dd46db69c94f8238dd47f568ca57bc51c0
> earlier, but that should only prevent you from opening new empty tabs with Ctrl+T.
> That seemed like an obvious bug, since the overview isn't designed to work in web
> app mode. You should still be able to create new tabs from links you find on webpages 
> (Ctrl+click, middle click, right click) in 3.28. Is that not working properly?

Correct, I have just verified again with 3.28.2. Right clicking on a link and selecting 'Open Link in New Tab' does nothing. It doesn't open a new tab nor does it load the link in the current tab. Ctrl-click opens the link in the current tab instead of opening a new tab. Middle click does the same. So far, I have been unable to open anything in a new tab with 3.28.2.

What is also very interesting, is if I navigate click on a link that takes me to a different domain, the back button becomes disabled (along with the context menu), so I have no way to go back!

I am running Fedora 28, with the 3.28.2.1-2.fc28 in the official repositories.

OK, I've reverted that commit for 3.28.3 to get back to the original 3.28 behavior on the 3.28 branch. (But I'll leave it unchanged in master, per the above commits.)

(In reply to Marcus Dillavou from comment #31)
> What is also very interesting, is if I navigate click on a link that takes
> me to a different domain, the back button becomes disabled (along with the
> context menu), so I have no way to go back!

I just got another report of this today. It sounds like a separate bug?

(In reply to Michael Catanzaro from comment #32)
> OK, I've reverted that commit for 3.28.3 to get back to the original 3.28
> behavior on the 3.28 branch. (But I'll leave it unchanged in master, per the
> above commits.)

Thanks!

> 
> (In reply to Marcus Dillavou from comment #31)
> > What is also very interesting, is if I navigate click on a link that takes
> > me to a different domain, the back button becomes disabled (along with the
> > context menu), so I have no way to go back!
> 
> I just got another report of this today. It sounds like a separate bug?

Probably because in 3.28.1, clicking on a link outside of the domain opens a new tab by default. Since it is a new tab, it doesn't have any history, therefore the back button is disabled. But in 3.28.2, clicking on a link outside of the domain opens the link in the current tab, also removing any history and disabling the back button.

Also, not to get too far off topic, but I actually found the button to create a new tab useful. In my Jira example in the previous comments, open a new tab shows the Most Visited page, which ends up being several pages that I use often in my Jira webapp. This lets me open a new tab and jump to a common report very easily, rather than clicking on a random link to open a new tab, then having to navigate (sometimes unsuccessfully) through Jira to get to that report. See:

https://s22.postimg.cc/kzlsoubsx/Screenshot_from_2018-06-01_10-21-45.png

Reply to  Marcus Dillavou (https://bugzilla.gnome.org/show_bug.cgi?id=796204#c29)

I have just accidentally found out that epiphany supports --class attribute that should set WM class of the window