allow window minimize & restore (focus)

[nadavsinai]

This is another feature missing from the web platform with regards to window management. There obvious use cases - especially for apps with multiple windows, and there used to be window.minimize sometime chrome extensions are used for this via chrome.windows.update(window.id, { state: 'minimized' })

In addition window.focus() has some interesting limitations that are worth re-visiting in this context - for example if a page was open using window.open without providing the noreferrer option the parent will be available as window.opener - but the child will not be able to call .focus() on the parent.

[Garbee]

I don't think it should be a blatant opener can get abilities while the child can't talk back. I do think it should be one-way, but it should be based on the child authorizing the parent to conduct such actions on it.

It gets into a deeper discussion about getRelatedApps and using that list to spawn windows and get more granular control that the related application has approval of (which could possibly include native as well.)

If we want to go down this rabbit hole now, I can write-up a quick explainer on my thoughts here. But for an initial attempt at the API I don't think we should consider this in-scope.

[nadavsinai]

@Garbee we can separate it to two issues: First is the ability to minimize one own window, and opened child windows (perhaps like mobile audio - only within a user event context) The second - ability of the window to focus itself or child windows. The ability of the parent to be focused by the child, can be remedied via agreed protocol for messages dispatched used postmessage which the parent can react on and call .focus() on itself, but the parent->child direction should be allowed, don't you think?

[Garbee]

minimize one own window

I believe Firefox and/or Chrome had this before and it was removed. Potential problem is pop-ups or other annoying things spin up, then minimize themselves to try and hide. It isn't something we'd want to re-introduce.

I think the only way forward is for the proxy window created by the window.open type methods to handle these functions. Of which, the proxied window must authorize the domain calling these methods to have access to do such functions (for more security/safety reasons.) Now, this can open the hole where someone specifically makes their pop-up target authorized by the client site to cause disruption. But it's still a higher barrier to entry and needs to be scrutinized just as thoroughly as any other method of allowing this behavior.

[nadavsinai]

HI, @michaelwasserman I see you assigned this issue to yourself. Our team at Philips-Algotec have successfully moved from Chrome-extension based window placement & screen enumeration to using the new APIs - however these issues I reported remain standing unresolved and force us to still keep the chrome extension.

Apart from the fact there is no API to preform window minimization we discovered that even .focus on own window does not work, so even if we implement our own protocol via postMessage to allow our app's inter-window workflows - proper window management is still lacking from the platform.

Any update on when these deficiencies in the API will be addressed?

[michaelwasserman]

Thanks for the ping, I'll paraphrase the use case you shared here for more context:

A medical app uses 3 windows: image viewer, report editor, worklist & patient information. These are often spread over 3 monitors, eg: report editor on 2MP normal HD display, images viewer on 3MP or 5 MP monochrome medical display Users can open multiple studies, and the windows must be kept in sync to avoid mismatch (eg. reading the report of one study whilst looking on the images of another) So if the doctor minimizes the report we must minimize the images etc. This is currently possible via chrome extension but should be available via the web platform.

The surrounding minimization, focusing, and child window use cases deserve strong consideration for future iterations of the Window Placement proposal, but aren't currently part of the active proposal. I attempted to capture the essence of these requests in additional_explorations.md, please lmk if I can refine those explorations to better match your requests and use cases. In general, these behaviors present complex value/risk tradeoffs that will need thoughtful privacy and security considerations, even if they are gated behind user permissions.

[jpambrun]

I also work a large PACS vendor and am facing the same issue. I understand there are complex security implications. The ability to self focus (i.e. not via interactions, and not from the opener) would be nice. Maybe such capabilities could be limited to installed PWA.

[ivansandrk]

@jpambrun @nadavsinai @etnos

Hey folks, re "focus"

Is there a use case you're try to solve or any additional information? Are you trying to bring a window on top? Are you trying to use focus gated functionality?

[nadavsinai-philips]

HI, This is @nadavsinai here - via my Philips Github username I now need to engage through since Philips acquired Carestream. The use case is session management, a workflow manager window opens viewer windows for each patient's reading (known as study) on multiple monitors, if the user decides to open a another study not "in-place" and instead spawn out new viewer windows we must (I believe by legislation) to minimize the other studies together so that there won't be a possibility of mistaking between the two. A user may re-focus the first study (via the workflow manager or otherwise) and all the rest of the windows must follow suit. to do that we need to be able to control the minimize and focus of other windows. Focus is doable nowdays with an opener an extensive post messaging (as the user intent may not start from the opener), but minimize is completely out of the platform's reach and it's a pity, we have to use an extension to be able to do that.

[gsmethells]

I also represent a large PACS vendor at Medstrat and we are running into the same concerns. Are these concerns going to be addressed?

[sonkkeli]

I also represent a large PACS vendor at Medstrat and we are running into the same concerns. Are these concerns going to be addressed?

You may follow the status from https://chromestatus.com/feature/5201832664629248?gate=5185992221261824