User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
Have an HTML file containing context-sensitive help. Each help block has a unique name, and the names are used in <a name="HELPNAME">. The attached buggy-target.html uses <hN id="TARGETNAME"> instead, but the same problem occurs.
To attempt to reproduce the problem with a much smaller file, I did the following:
First, but probably not a FF problem, but rather a Windows problem, but I'm not sure, I tried the command:
It goes to the top of the file, and the #target4 part of the URL is not displayed in the address bar. This makes me think that Windows is dropping the #target4 part. But it is also possible that since Firefox has an undocumented -osint command-line parameter, which seems to be included in the .html shell open command for the FF browser when it is set as the default browser, that somehow it is causing the problem.
I created an AutoHotKey script to emulate what I think Windows is supposed to be doing. It will be attached as a subsequent comment. In the AutoHotKey script, I look up the default browser, and then the command, and then substitute the URL (only) parameter to the AHK script as a replacement for %1 in the shell open command. Then I tried the following:
This successfully took me to the right place in buggy-target.html, and the #target4 part was not missing from the URL.
Then I executed the same command again, and this time it opens a new window (actually tab the way my FF is configured) and goes to some other place in the file.
Additional executions go to that same other place.
Using any of the other targets produces a similar result... if the file is not already open, the target has the right effect, but if it is already open, it doesn't have the right effect. The 2nd and subsequent uses of the same target seem to result in the same location in the file as each other, but not the correct location as the first time.
Pasting the URL into the address bar of many tabs results in the correct location every time.
Putting the file on a web server, and using the https: scheme instead of the file: scheme results in the correct location every time.
Using Chrome or Chromium-based Edge results in the correct location every time.
So it is just this one case, of a file scheme, with a target, already opened, that fails.
Then I got clever
see discussion above
Well, it would be nice to get to the correct location 100% consistently. It is not clear why one browser window/tab would affect another, as generally they don't, and shouldn't.