After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 796431 - In web app mode, Web opens links in the current tab, breaking the app instead of loading links in new tabs.
In web app mode, Web opens links in the current tab, breaking the app instead...
Status: RESOLVED DUPLICATE of bug 796204
Product: epiphany
Classification: Core
Component: Web Applications
3.28.x
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2018-05-28 02:08 UTC by Ryan Farmer
Modified: 2018-05-29 02:46 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ryan Farmer 2018-05-28 02:08:54 UTC
It seems that in Web 3.28.2.1 on Fedora 28, in application mode, Epiphany opens links in the current tab, replacing the web app instead of loading the link in a new tab.

This is breaking at least my Facebook and Riot web apps because the back button is also disabled, leaving no way back to the web app without closing the window and re-opening the web app.

I'm guessing that it has something to do with commit c56294dd, ""Again disallow new tab action in app mode".

https://gitlab.gnome.org/GNOME/epiphany/commit/c56294dd46db69c94f8238dd47f568ca57bc51c0
Comment 1 Michael Catanzaro 2018-05-28 14:08:53 UTC
(In reply to Ryan Farmer from comment #0)
> I'm guessing that it has something to do with commit c56294dd, ""Again
> disallow new tab action in app mode".

No, that just prevents using Ctrl+T to open a useless overview tab. It's surely caused by bug #788845.

Do you think your issue is a duplicate of bug #796204 (different), or is the behavior you want a bit different? I'm considering using that bug to revert web apps back to the 3.26 behavior.
Comment 2 Ryan Farmer 2018-05-28 18:50:55 UTC
Opening links from web apps in the main browser would be ideal. 

No, this isn't a duplicate because, in my case, the links open in the web app, but not in a new tab. 

They replace the web app and the back button doesn't work. So it's no longer a web app. It's more like a broken browser at that point until you close what was the web app window and re-open the app. As soon as you click a link, it happens again.
Comment 3 Ryan Farmer 2018-05-28 20:45:24 UTC
Actually, I think that the behavior the reporter of bug #796204 wants would have been correct for a while, I just never got around to making such a request myself. 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. 

I'll go ahead and put this comment on the other bug too in case it's useful in the discussion going on there.
Comment 4 Ryan Farmer 2018-05-28 23:25:31 UTC
Comment 3 on bug #796204 sounds like my issue.
Comment 5 Michael Catanzaro 2018-05-29 02:28:42 UTC
(In reply to Ryan Farmer from comment #3)
> 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.

That's a GTK+ bug, https://gitlab.gnome.org/GNOME/gtk/issues/624. The function to display the window doesn't work. There are some evil workarounds discussed there, but ultimately GTK+ just needs to be fixed.

> 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.

See the GTK+ issue for the workaround Firefox may be using. The behavior you want is definitely the expected, non-broken behavior...

> 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.

...and that is why.
Comment 6 Michael Catanzaro 2018-05-29 02:46:41 UTC
Should be fixed by the changes in bug #796204, so let's treat it as a duplicate.

I'd appreciate testing, if you want to confirm that the behavior is as you desire. Normally I'd suggest using Epiphany Technology Preview, but web apps are disabled there, so to test this you'd need to build it yourself, unfortunately. If you want to do that, then, to avoid building WebKit, you could take the gnome-3-28 branch to avoid the WebKitGTK+ 2.21.1 dependency, and revert the same patches that I just reverted on master there.

*** This bug has been marked as a duplicate of bug 796204 ***