1341711 - window.open and handles to windows of a domain and .focus() problems

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[TREMBLAY,Bernard]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

Try to use window.open to manage a family (same domain+port) of windows (or tabs).
Create new tab or get handles (verify) to existing windows using hw = window.open('', uniquename, '') and set focus using HTMLElement.focus() (hw.focus() to give focus to hw)


Actual results:

HTMLElement.focus() (hw.focus() to give focus to hw for example) doesn't function.

All tabs (or windows) whose name is known can be reached (get hw using window.open) and data manipulated from any tab or window or the "family" but focus cannot be transmitted to. 


Expected results:

issuing for a window handle known and valid : hw.focus() should give focus to hw.
(note that window.open has various behavior for different navigators.
See my note : https://developer.mozilla.org/en-US/docs/Web/API/Window/open)

This is not for extensions development which have tabs library but for web applications which must be full compatible with multiple navigators and devices.

So I propose also an extension of window.open :

hw = window.open('',name,'check=yes') would return 
- the window handle when "name" exists into the family (domain+port) - no matter the way they have been generated if they are windows of the domain+port. 
- null if the window "name" doesn't exist (note that without the "check=yes" parameter the current default behavior is to open an empty new window (or tab in current window if no parameters are given).

This proposal of enhancement assures full back compatibility and doesn't generates in my opinion (but I am not a specialist) any known security problem (except resource exhausted if an error of soft generates a loop). 

This is a key to be able to share (and check) the handles into a family of tabs or windows and avoids to re-open (if wished by development) already opened tabs with same url (a bi-univoque relation between names and handles into a family).

The current Firefox behavior doesn't allows to check if a named tab is still opened which can create incoherencies (asynchronous actions). This because if the name doesn't exists a new empty window or tab will be created by window.open, this way to check a currently existing name is usable for test, not for production.

Note that Chrome (56.0) has currently a completely different behavior and should, in my opinion follow (as most navigators) the same way as Firefox for this command.

It exist a long discussion in French :    https://www.developpez.net/forums/d1579188/webmasters-developpement-web/javascript-ajax-typescript-dart/javascript/re-ouvrir-acceder-fenetre-grace-name-se-passe-til-name-duplique/
that I have initiated.

I explain there why with this extension of window.open, it become possible to avoid to open multiple time the same url of a domain and navigate easily between tabs of a family (particularly to manage great documents).

note : I have set this into bugs because I believe that HTMLElement.focus() should activate the tab of HTMLElement if the element is valid.
For the proposal it is sure that it is an enhancement. I have for now kept them together because they are strengthen linked.

Best regards
Trebly

Comment 1

[Andrew Overholt [:overholt]]

Anne, can you take a look at comment 0 and see how things align with the current spec? Thank you.

Comment 2

[Anne (:annevk)]

Someone from UX would have to look at this. It doesn't necessarily seem like a good thing to allow applications to control which window gets focus, although sometimes (e.g., when clicking a "desktop" notification) it's reasonable.

Comment 3

[TREMBLAY,Bernard]

"It doesn't necessarily seem like a good thing to allow applications to control which window gets focus"

The concept is that exclusively into a domain+port the application can give the focus to any of the windows (tabs) of the family. Currently as I have explained Chrome allows this from a window which has opened a child using window.open but not between sibling nor from the child to the parent.

The typical sample of application is a long document (books user manul etc..) splitted in section (WordPress use of <!--nextpage--> pseudo tag - WP use 'page' with a minimum of of four meanings). Then each section have a different url (into same domain). We can easily imagin tha

Comment 4

[TREMBLAY,Bernard]

(accident...) that we want to display (focus) the "section bibliography" for a fragment targeted by a link. We want also, focus successively the different fragments without reopening the bibliography each time. We want to be able to open a second section from a table of contents (shared between all section and displayed onto a side tip) and do the same from the new opened section ( the sibling of the first).

I have worked one year on such feature without finally success (and developed a full library to manage it). It cannot function because it is impossible to maintain correctly the list of "truly opened and currently valid" tabs. I can get (generate and update) naturally the table of opened tabs and share it, but it is impossible to "focus" tabs and fragment (HTMLElements). With ten sections (150 pages equivalent book) and three hundred links,  write notes, comment the document, verify coherency, compare, create and verify links is currently quite impossible using numeric tools.

Currently the lonely valid way is to print on paper separately each chapter and bibliography and index..., use sticks, list of pages and manual notes and when job is ended copy data onto the numerical document. Then just adjustments remains to perform by a numeric way.
 
But the user will ever remain with as many bibliography opened as sections opened and cannot focus an element of bibliography from a link to (same for dictionaries, index...).

This is a part of the explanation of my sentence from my first comment :
<I explain there why with this extension of window.open, it become possible to avoid to open multiple time the same url of a domain and navigate easily between tabs of a family (particularly to manage great documents).>
I can explain in details the mechanisms involved and translate the French text to English if needed.

I hope to have convince you of how important are the aims conditioned by the availability of such feature.

Comment 5

[Andrew Overholt [:overholt]]

Bernard, it might be best to take this to another forum. Anne, are DOM or HTML spec issues [1, 2] the best place for such discussions? Or the whatwg mailing list [3]?

[1]
https://github.com/whatwg/dom/issues

[2]
https://github.com/whatwg/html/issues

[3]
https://whatwg.org/mailing-list

Comment 6

[Anne (:annevk)]

[2] I suppose, but since it's UI the standard can only say so much. Implementers have to decide what is and what is not acceptable for their users.

Comment 7

[TREMBLAY,Bernard]

Hi,

OK, but I have not set Product and component. Ir is sure that the problem is not there, it is js and his versions.

But where to migrate ? the question :
1- what can be considered as bug or not well ended functions
2- Extensions for development.

The question doesn't involves immediately DOM or farther HTML.

After all considerations, I summarize some questions of specifications :

1- When a js application opens a new window :
    - do when the window is closed by user the application can be allowed to decide to reset focus to opener
         - when window is opened using window.open 
         - when window is opened by A tag
    - do when a window is opened by a site (HTML or js application - which can catch events) the js application can hold the process and set focus to the same tab when url(s) targeted has the hash as lonely difference 
         - do in this case the js application can be allowed to set focus directly to the defined fragment (currently the whole page is reloaded)
         - do various tabs of same domain+port (opened by various means) and using same script can be allowed to focus an existing opened tab which has the targeted url better than reopen a new one (duplicate)

2- when user closes a tab which can be the rights of the application to move focus to another window of the same application, other window which will be able to ask a question to user : you have closed the tab what do you want to do now ?

Sorry, I have tenth of such questions for which current answer is "no right", no way to do it.

I would be able to be understood by somebody.

Comment 8

[Alexandra Govorkova]

Hi guys! 
Any updates on this issue? Or workaround how to focus child window? 
Thanks!

Comment 9

[TREMBLAY,Bernard]

Hi,

No really nothing else than my own tests.

I have tested the use of an object (a library that I developed) containing all useful references to opened windows.
This object (tabs) can be easily shared between windows each window getting an Id (his name) when it is created.
The data which are not handles are saved in localstorage.
When a window get focus the datas are checked (comparison of current object with localstorage) and if in the array of known windows the handle is null the window is declared inactivated and stored in history (if it is validated the window can be normally re-opened by his name).

This should function even there is no function as proposed to check if a named window is currently opened (has an handle) or not.

In fact my object  window.tabs which should be accessible from any window and normally identical for windows which have known handles from any window with name "tabs", creates dysfunctions and generates crashes. The behavior is different between browsers I could not spend time to find exactly how to deal with this problem.

It seems that the instruction h=window.open("name") which should be (I don't find  just now where this is specified ) into a domain is not correctly applied and the rule is that this is often valid only when the instruction is issued from a "parent" window (this concept becoming obsolete). Then I believe that because I get back a null handle for a really and correctly named window (into a domain) my library crashes trying to create again this repeatedly (trying to synchronize) and exhausting system resources. 

For me the problem remains opened. I have inactivated many functions into my development and currently the system is only able to open already opened window which are a child of the window currently focused. The other windows which are not visible (not same parent) are reopened which is ergonomically bad. But I could not find any solution.

Note that in my opinion this problem involves the DOM but obviously too the management of data into the browser. This is the reason why window.open() is not a part of DOM, but the data manipulated are. "tabs" object used in browser by plugins which manages tabs with corresponding rights are connected with this problem. HTML is not truly directly involved.

Consequently the whole problem is around the concept of "rights of domain manager" in manipulating tabs of the domain (the old and obsolete - but remaining in code of browsers - concept of dependence between parents windows and their children is necessarily crashing against the concept of "domain manager").

Nevertheless I go on in thinking that my proposal of an easy way to check if a window is known into a domain should be a progress without any risk. It will allow to overlap the limitation of access of windows to their parents going simply towards the concept of "domain manager" for whom wishes it. In such context the specification "[window.open('name')] which always returns the handle of a window opened into a domain" is in perfect correspondence. My proposal is an enhancement of this function.

Best regards

Trebly

Comment 10

[Jessica Munoz]

Attachment: sporanmeuvi19796501.txt

Thanks from fungbubbtaver1970.