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 685976 - Epiphany ignores gnome-shell open-new-window hint
Epiphany ignores gnome-shell open-new-window hint
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: General
3.6.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Gustavo Noronha (kov)
Epiphany Maintainers
: 686762 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-10-11 14:23 UTC by Michael Gratton
Modified: 2018-03-26 05:11 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Partial fix - open links in new windows if last active window is not in the current workspace (3.54 KB, patch)
2012-12-09 14:35 UTC, Gustavo Noronha (kov)
none Details | Review
Partial fix - open links in new windows if last active window is not in the current workspace (3.56 KB, patch)
2012-12-09 14:39 UTC, Gustavo Noronha (kov)
none Details | Review
Opens new windows when no URIs are given for Web to load (1.92 KB, patch)
2012-12-09 15:47 UTC, Gustavo Noronha (kov)
none Details | Review
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic (2.14 KB, patch)
2012-12-09 20:04 UTC, Gustavo Noronha (kov)
none Details | Review
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic (4.52 KB, patch)
2012-12-10 11:48 UTC, Gustavo Noronha (kov)
none Details | Review
Opens new windows when no URIs are given for Web to load (7.08 KB, patch)
2012-12-10 17:07 UTC, Gustavo Noronha (kov)
none Details | Review
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic (5.47 KB, patch)
2012-12-10 17:16 UTC, Gustavo Noronha (kov)
committed Details | Review
Opens new windows when no URIs are given for Web to load (3.85 KB, patch)
2012-12-10 17:16 UTC, Gustavo Noronha (kov)
committed Details | Review

Description Michael Gratton 2012-10-11 14:23:31 UTC
In gnome-shell, there are at a number of ways to open a new window for an existing application on a specific workspace. These make working with multiple workspaces reasonably convenient (despite) GNOME's current application-centric direction.

Epiphany 3.6.0 does not respect this however, and always opens a new tab in the last used window, regardless of the target desktop.

To reproduce:

1. Launch Epiphany
2. Drag the Ephy application icon in the dock to a workspace that does not contain an Epiphany window

A new Ephy window should open in the target workspace, but instead a new tab opens in the last used Ephy window.

This behaviour seems to be inconsistent with most other GNOME and non-GNOME apps, and was not the case for the majority of the 3.5.x series and earlier, thus is a regression.
Comment 1 Xan Lopez 2012-10-18 16:11:50 UTC
OK, so the story is: after *a lot* of complaints we finally made epiphany respect the "always open windows in new tabs" setting in this case too. I think the fact that this is happening to you means you have this setting enabled (you can check org.gnome.epiphany.new-windows-in-tabs). A simple workaround would be to create a launcher that forces new windows (with -n), but reverting this will just make all that bunch of people angry again.
Comment 2 Michael Gratton 2012-10-19 00:11:50 UTC
You're right - I have org.gnome.epiphany.new-windows-in-tabs set to true. I set it originally since I want target="_new" links and other popups to open in tabs. That, and opening new windows at the request of the user seems to be two separate preferences.

However, I'm genuinely confused as to why people are complaining about Ephy opening new windows when /explicitly/ asked to do so — it's like complaining that hitting Ctrl+N open a new window rather than a new tab. Explicitly asking for a new window is exactly what is happening in these gnome-shell scenarios:

1. Right-click the Ephy icon in the dock and choose "New window"
2. Search for Ephy, and hold down Ctrl when hitting Enter
3. Drag the Ephy icon to a workspace that has no existing Ephy windows
 
In all these cases, regardless of user preferences, a new window should be opened since the user is taking extra effort to ask for just that. For everything else open a tab if new-windows-in-tabs is true, but again that should probably be split into a UI and a web preference.

Adding a new launcher with -n won't work, since when there is already an Ephy window open on a workspace and invoke it normally in gnome-shell, I want the existing window to open (consistent with standard gnome-shell behaviour).
Comment 3 Claudio Saavedra 2012-11-02 07:42:19 UTC
*** Bug 686762 has been marked as a duplicate of this bug. ***
Comment 4 Gustavo Noronha (kov) 2012-12-09 14:35:04 UTC
Created attachment 231071 [details] [review]
Partial fix - open links in new windows if last active window is not in the current workspace

The problem described in by the reporter is fixed by this patch. However, if you drag Web's icon or use the 'New window' menu item while on a workspace that has your last active window, then it will open a new tab on that window. I'll try to figure out how gnome-shell tells us it wants a new window.

I'm also wondering about using the last active window. If I have a window full of cat pictures in workspace 1, and a window with bugzilla bugs in workspace 2, if I go to ws 1 to look at cats, then come back to ws 2 and, without making the web window which is there active, click a new bugzilla link, then the link will be opened in the web window which is in ws 1. Perhaps it would be better to always look for a window in the current workspace, and if it doesn't exist, then open a new window?
Comment 5 Gustavo Noronha (kov) 2012-12-09 14:39:03 UTC
Created attachment 231072 [details] [review]
Partial fix - open links in new windows if last active window is not in the current workspace
Comment 6 Gustavo Noronha (kov) 2012-12-09 15:47:21 UTC
Created attachment 231081 [details] [review]
Opens new windows when no URIs are given for Web to load
Comment 7 Gustavo Noronha (kov) 2012-12-09 15:56:30 UTC
FWIW, we had a small chat here in the hackfest and I came up with this page about what we would like to have: https://live.gnome.org/Design/Web/OpeningLinks
Comment 8 Gustavo Noronha (kov) 2012-12-09 20:04:04 UTC
Created attachment 231096 [details] [review]
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic

This patch makes 231072 obsolete. It can be easily made to mean 'the window with most tabs', without the 'in the current workspace' restriction, too, just by removing the is_on_current_workspace() check. If we decide to do that, though, I'd like to add a 'always-current-workspace' setting ;)
Comment 9 Gustavo Noronha (kov) 2012-12-10 11:48:49 UTC
Created attachment 231141 [details] [review]
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic

Full patch, including the stuff we need from the first
Comment 10 Diego Escalante Urrelo (not reading bugmail) 2012-12-10 14:58:00 UTC
Also consider this bug: https://bugzilla.gnome.org/show_bug.cgi?id=115732
Comment 11 Gustavo Noronha (kov) 2012-12-10 17:07:34 UTC
Created attachment 231170 [details] [review]
Opens new windows when no URIs are given for Web to load
Comment 12 Gustavo Noronha (kov) 2012-12-10 17:16:03 UTC
Created attachment 231172 [details] [review]
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic
Comment 13 Gustavo Noronha (kov) 2012-12-10 17:16:32 UTC
Created attachment 231173 [details] [review]
Opens new windows when no URIs are given for Web to load
Comment 14 Xan Lopez 2012-12-10 18:44:59 UTC
Review of attachment 231172 [details] [review]:

::: src/ephy-shell.c
@@ +1061,3 @@
+	EphyWindow *window = NULL;
+  GList *windows;
+	GList *iter;

Indentation seems to be massively broken in this method.

@@ +1063,3 @@
+	GList *iter;
+
+  g_return_val_if_fail (EPHY_IS_SHELL (shell), 0);

Dude, NULL.
Comment 15 Gustavo Noronha (kov) 2012-12-10 19:55:43 UTC
I blame gedit for the indendation. Fixing in emacs now =P
Comment 16 Xan Lopez 2012-12-11 09:29:23 UTC
Review of attachment 231173 [details] [review]:

I think this makes sense. As we have discussed I really dislike this code, but it's not your fault. We can figure out how to improve it later.

::: src/ephy-session.c
@@ +274,3 @@
 		flags |= EPHY_NEW_TAB_FROM_EXTERNAL;
 	}
+	if ((options != NULL && strstr (options, "new-window") != NULL))

Why the extra parenthesis?
Comment 17 Gustavo Noronha (kov) 2012-12-11 12:32:25 UTC
Left over from a previous try/experiment.
<xan> ok
Comment 18 Gustavo Noronha (kov) 2012-12-11 12:41:56 UTC
Comment on attachment 231172 [details] [review]
Replaces the current last active window heuristic with a "window with the most tabs in the current workspace" heuristic

c968c68cabc319896ad4d2096940c9a34d4c13cd
Comment 19 Gustavo Noronha (kov) 2012-12-11 12:45:32 UTC
Comment on attachment 231173 [details] [review]
Opens new windows when no URIs are given for Web to load

b7f88ee85c61fee4f8059e7fc2456c3ca83ccb64
Comment 20 Reinout van Schouwen 2012-12-29 23:02:17 UTC
Window with the most open tabs in current workspace? As long as bug 330676 isn't fixed, that would lead to "disappearing" tabs, I'm afraid.
Comment 21 Michael Catanzaro 2018-03-25 17:49:50 UTC
This is a mass NEEDINFO of all Epiphany bugs with no activity in the past three years. I'm going to be automatically closing old bugs to help us focus on current problems. If you feel this bug is still relevant with Epiphany 3.26 or newer, then please leave any comment here so that I know not to close this one.
Comment 22 Michael Gratton 2018-03-26 05:11:43 UTC
I don't know if there is anything to do here now. Running 3.28 and with new-windows-in-tabs set to true, points (1) & (2) in comment #2 now seem to be working as expected, and (3) doesn't but its seems to be broken in shell at the moment - it doesn't work for e.g. Nautilus either.