1346691 - The following link does not work correctly with the same target.

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect, P3)

Description

[proverkatarget]

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170302120751

Steps to reproduce:

(Google translate) There are two identical tabs, let's call them "Tab 1" and "Tab number 2". In the first tab, we click on the link with target = "123". A new tab is opened, let's call it "Tab from the link". Next, go to the tab "Tab number 2" and click on the same link with target = "123". 
(Original) Есть две идентичные вкладки, назовем их "Вкладка №1" и "Вкладка №2". В первой вкладке мы нажимаем ссылку с target="123". Открывается новая вкладка, назовем ее "Вкладка из ссылки". Далее переходим на вкладка "Вкладка №2" и нажимаем на ту же ссылку с target="123". 


Actual results:

(Google translate) A new tab has been opened.
(Original) Открылась новая вкладка.


Expected results:

(Google translate) The new tab does not open, but the already opened tab "Tab from the link" is updated.
(Original) Новая вкладка не открывается, а обновляется уже открытая вкладка "Вкладка из ссылки".

Comment 1

[:Gijs (he/him)]

Is this a dupe of bug 1303838? I guess it's hard to tell without more information (such as a testcase that reproduces the problem).

Comment 2

[Samael Wang [:freesamael] (away for now)]

(In reply to :Gijs from comment #1)
> Is this a dupe of bug 1303838? I guess it's hard to tell without more
> information (such as a testcase that reproduces the problem).

No, I don't think it's the same thing. I think the problem here is that nsDocShell::DoFindItemWithName only checks for names in the same TabGroup. If user manually opens 2 tabs, and then navigate both tabs to the same URL, the 2 tabs and links they opened would result in 2 diffferent TabGroups.

If I didn't misinterpret the spec, "Tab number 2" should be familiar with "Tab from the link" assuming they're in the same origin [1]. However I don't have a good solution for the problem. Because in reality "Tab 1" + "Tab from the link" could be in one process while "Tab number 2" be in another different process.

I tried on Chrome 57, the behavior depends on whether "Tab 1" is in the same process with "Tab number 2". If they're in different processes the behavior is the same as Firefox, otherwise it behaves as expected result in comment 0.
 
[1] https://html.spec.whatwg.org/multipage/browsers.html#familiar-with

Comment 3

[proverkatarget]

(In reply to Samael Wang [:freesamael] from comment #2)
> (In reply to :Gijs from comment #1)
> > Is this a dupe of bug 1303838? I guess it's hard to tell without more
> > information (such as a testcase that reproduces the problem).
> 
> No, I don't think it's the same thing. I think the problem here is that
> nsDocShell::DoFindItemWithName only checks for names in the same TabGroup.
> If user manually opens 2 tabs, and then navigate both tabs to the same URL,
> the 2 tabs and links they opened would result in 2 diffferent TabGroups.
> 
> If I didn't misinterpret the spec, "Tab number 2" should be familiar with
> "Tab from the link" assuming they're in the same origin [1]. However I don't
> have a good solution for the problem. Because in reality "Tab 1" + "Tab from
> the link" could be in one process while "Tab number 2" be in another
> different process.
> 
> I tried on Chrome 57, the behavior depends on whether "Tab 1" is in the same
> process with "Tab number 2". If they're in different processes the behavior
> is the same as Firefox, otherwise it behaves as expected result in comment 0.
>  
> [1] https://html.spec.whatwg.org/multipage/browsers.html#familiar-with


(Google translate) You completely correctly described my bug. It turns out that if the tabs are in different processes, they will not be connected in any way. Is it possible to fix this so that the connection between the tabs is not lost?

(Original) Вы полностью правильно описали мой баг. Получается если вкладки окажутся в разных процессах, они никак не будут связаны. Возможно это как то исправить, чтобы связь между вкладками не терялась?

Comment 4

[Samael Wang [:freesamael] (away for now)]

The current spec of browsing context name searching is somewhat conficting with our multiprocess modeling. Since 2 tabs with the same origin documents could be in different processes, and therefore couldn't easily access each other by names.

Had a short discussion with :annevk, and confirmed that the direction is to fix the spec by limiting the name searching scope to "the unit of related browsing contexts" [1] that would allow more process opportunities. Therefore we're not going to change Firefox's current behavior.

[1] https://github.com/whatwg/html/issues/1440#issuecomment-299116416

Comment 5

[proverkatarget]

(Google translate) You can try using shared memory to exchange names of tabs between processes, this will let you know whether or not such a tab is open.
If we know that the tab is open in another process, then you can not open the tab and still implement the following:

1. if you want to switch to an open tab, then give the corresponding signal to another process;
2. If you want to light an open tab, then give the corresponding signal to another process;

(Original) Можно попробывать использовать shared memory для обмена именами tabs между процессами, то это позволит узнать открыта или нет такой tab.
Если узнаем, что tab открыт в другом процессе, то можно вкладку не открывать и еще реализовать следующее:

1. если нужно переключиться на открытый tab, то подать соответствующий сигнал другому процессу;
2. если нужно подсветить открытый tab, то подать соответствующий сигнал другому процессу;

Comment 6

[:Gijs (he/him)]

(In reply to proverkatarget from comment #5)
> (Google translate) You can try using shared memory to exchange names of tabs
> between processes, this will let you know whether or not such a tab is open.
> If we know that the tab is open in another process, then you can not open
> the tab and still implement the following:
> 
> 1. if you want to switch to an open tab, then give the corresponding signal
> to another process;
> 2. If you want to light an open tab, then give the corresponding signal to
> another process;

Opening links or switching to another tab is not the main problem. The problem is that in JS / the DOM, you can get a reference to a named window when using window.open(), and getting such a reference across processes (and expecting to be able to do things with it using the DOM, synchronously) doesn't work. Making this 'half' work (by only making link clicks work, but not window.open()) would be even worse, because then the web code can work out that such a window exists (because it can tell the user clicked the link with e.g. a mouse event handler), but when trying to access it using window.open(), it will create a different window. Obviously that would break web specifications as well.

Comment 7

[proverkatarget]

I'm understood, thank you. I will redesign the site code for Javascript.