From message posted to LO Users mail list:
Jan 06, 2020; 8:13pm — by snowshed
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?
The Windows 10 'Task View' button, and the 'Virtual Desktop Manager'  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.
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?
With which browser was it tested? I couldn't repro with LO 188.8.131.52 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...
@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.
@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 ?
Dear V Stuart Foote,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
(In reply to QA Administrators from comment #5)
Issue is still present with FireFox (rel 91.0.2) however, it will not jump to an alternate task view 'desktop' if FireFox is not already running. Without FF running, a launch of the help will open the new browser into the same task view desktop where LO is running.
But if FF is already open in another task view virtual 'desktop'--launching the help article (local or online web delivered) will jump to that desktop.
Chrome, MS Edge do not behave that way and open a new browser when needed on the active task view 'desktop'.
Resolving Not Our Bug as the inability for LO help to open on correct task view "virtual desktop" is internal to FF.
Version: 184.108.40.206 (x64) / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US