Open Bug 1565950 Opened 1 year ago Updated 1 year ago

file: scheme with #target goes to wrong spot in 2nd window or tab

Categories

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

68 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: v+mozbug, Unassigned)

Details

Attachments

(2 files)

445 bytes, text/html
Details
513 bytes, application/octet-stream
Details
Attached file buggy-target.html

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:

start file:///D:/my/html/buggy-target.html#target4

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:

browser.ahk file:///D:/my/html/buggy-target.html#target4

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

Actual results:

see discussion above

Expected results:

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.

Attached file browser.ahk

Also affects DevEdge.

DevEd that was supposed to be. Also affects FF DevEd.

Hi @Glenn Linderman, please add a simply TC to describe the issue, cannot figure it out what you what to say. It it a FF problem or not?
I'm confuse with the description.
For the moment I can only add a component, if isn't the right one please fell free to change it.
Thanks.

Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(v+mozbug)
Product: Firefox → Core

Further testing with other browsers by a friend that has a bunch installed determined that regardless of the browser, the first symptom, saying:

start file:///D:/my/html/buggy-target.html#target4

goes to the top of the file, and the #target4 text is not in the address bar, seems to be a Windows problem. None of the browsers wind up with #target4 in the address bar, and all of them go to the top of the file with the above command. So my friend, who is a Windows Insider user, reported that problem to them.

My test case submitted above was trying to figure out what the above start command was doing, and how it did it, but didn't reproduce the problem with the same symptom. Instead, it uncovered a different symptom, which seems to be a Firefox problem. The AHK script tries to read the registory and do the same thing the start command does, but regardless of what the start command does, what the AHK script does, on my system, is produce the following command, which is obtained by reading the registry and substituting the URL. The following command, used at a CMD prompt, produces the same symptom as when using my AHK script on my system. Of course, on other systems, paths to Firefox and/or my test file may be different.

"C:\Program Files\Firefox\firefox.exe" -osint -url "file:///D:/my/html/buggy-target.html#target4"

So the problem is, that with the browser not started, or started but not having the buggy-target.html file loaded, the above command works fine: it loads buggy-target.html, and positions it in the window, such that the #target4 (which leads to a spot in the file that has text "target 4") appears at the top of the window, and that the full URL is visible in the address bar (unlike with the Windows start command). This seems to be to be correct behavior, even though I have no clue what the -osint parameter that is read from the registry means: I couldn't find documentation for it.

However, if Firefox is already loaded, and is already displaying the buggy-target.html file, then the above command acts differently: the proper URL still appears in the address bar of the new window or tab that opens, but the file is positioned so that I see "target 2" in the middle of the window, instead of seeing "target 4" at the top, like I think it should.

Hopefully, this further explanation and detail will clarify the issue. Thanks for your response.

Flags: needinfo?(v+mozbug)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.