Bug 129870 - Browser based help not aware of Windows 10 'Task View' - 'Virtual DesktopManager', and can open system web browser displaying help in wrong workspace
Summary: Browser based help not aware of Windows 10 'Task View' - 'Virtual DesktopMana...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Documentation (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: needsWindows10
Keywords:
Depends on:
Blocks: New-Help
  Show dependency treegraph
 
Reported: 2020-01-07 20:57 UTC by V Stuart Foote
Modified: 2020-02-17 11:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2020-01-07 20:57:16 UTC
From message posted to LO Users mail list:

Jan 06, 2020; 8:13pm — by snowshed
<quote>
I found a less than desirable design flaw, at least while using Task 
Views in Windows 10.  Did anyone actually try it?

Have LO running in one view.  Have your browser open in another view. 
In LO, press F1 to open the help file.  It opens in the browser in a 
different task view, not in the view where LO is.  So you have to switch 
views, disconnect the help tab, and move the new browser window to the 
view where LO is.

What happened to the simplicity of having the help file simply open in a 
dedicated window in the same view as LO?
</quote>

The Windows 10 'Task View' button, and the 'Virtual Desktop Manager' [1] workspaces require new native code to link launch of the system browser holding the new Help (offline or project served) to the calling instance of LibreOffice.

Otherwise the launch of the user's chosen web browser can be into any workspace and require the actions described to relocate it to the same virtual desktop where LibreOffice is running.
 
=-ref-=
[1] https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ivirtualdesktopmanager
Comment 1 V Stuart Foote 2020-01-07 21:12:55 UTC
Task is Windows 10 native code to identify the Virtual Desktop LibreOffice is running in, and then on launch of the LibreOffice Help to be sure that ends up in the same Virtual Desktop.

Likely will require native Windows 10 os/DE dev work, similar to what had been done for the Windows 7 Jump Lists of bug 35785

@Jesus, you up for another round?

=-ref-=

https://stackoverflow.com/questions/30487556/detecting-active-virtual-desktop-on-windows-10-task-view-virtual-desktop-swi

http://www.cyberforum.ru/blogs/105416/blog3671.html
Comment 2 Mike Kaganski 2020-01-07 22:20:02 UTC
With which browser was it tested? I couldn't repro with LO 6.4.0.1 x64 and Chrome version 79.0.3945.88 x64 running on Windows 10.0.18363.

My perception is that it is a task for the browser. LibreOffice does *not* create the help window (which it could control); it executes an application associated with HTML and passes requested URL there. The called application might consider the desktop its launch was associated with, or it might ignore it, and detecting another instance of itself, just open a new tab in existing window on another desktop. But I only made a cursory glance...
Comment 3 V Stuart Foote 2020-01-07 22:46:45 UTC
@Mike, you may be right that the issue will lay with the web browser.

Adjusting the default system browser (what gets called by LO):

Just FireFox (71.0) is jumping to another Virtual Desktop workspace. 

Edge (11.0.18362.418), Chrome (79.0.3945.117) and IE11 (11.418.18362.0 but doesn't run the .js for the Help) all stay with the LO instance in the calling workspace.
Comment 4 Xisco Faulí 2020-02-17 11:06:21 UTC
@V Stuart Foote, Considering it's only happening with Firefox and not with the other browsers, do you think it's a firefox's problem and not a LibreOffice's one ?