Hello all,

I've got a file:///c:/folder/file.htm#foobar link, which opens, in FF v52,
the local file as expected. Wat it /doesn't/ do however is to go to the
"foobar" anchour (which exists, and can be jumped to using the in-page
"menu").

Is this expected behaviour for the "file://" protocol, or is there something
I'm missing in the above ?

Regards,
Rudy Wieser

R.Wieser wrote:

> I've got afile:///c:/folder/file.htm#foobar link, which opens, in FF v52,
> the local file as expected. Wat itdoesn't do however is to go to the
> "foobar" anchour

I can repeat it here, but it seems to be a windows issue, not a firefox
issue?

My shortcut includes my #anchor in the URL, but the firefox address bar
doesn't show the #anchor once launched, if I manually add the #anchor
inside firefox and re-load, it works and jumps to the relevant point in
the document.

On 6 Jan 2024 10:22:48 +0100 R.Wieser wrote:
>Hello all,
>
>I've got a file:///c:/folder/file.htm#foobar link, which opens, in FF v52,
>the local file as expected. Wat it /doesn't/ do however is to go to the
>"foobar" anchour (which exists, and can be jumped to using the in-page
>"menu").
>
>Is this expected behaviour for the "file://" protocol, or is there something
>I'm missing in the above ?

Is the mime-type text/plain?
<https://bugzilla.mozilla.org/show_bug.cgi?id=660583>
--
(Remove numerics from email address)

Dave Royal <dave@dave123royal.com> wrote:

> On 6 Jan 2024 10:22:48 +0100 R.Wieser wrote:
>>Hello all,
>>
>>I've got a file:///c:/folder/file.htm#foobar link, which opens, in FF v52,
>>the local file as expected. Wat it /doesn't/ do however is to go to the
>>"foobar" anchour (which exists, and can be jumped to using the in-page
>>"menu").
>>
>>Is this expected behaviour for the "file://" protocol, or is there something
>>I'm missing in the above ?
>
> Is the mime-type text/plain?
> <https://bugzilla.mozilla.org/show_bug.cgi?id=660583>

I tested using a local file set for a web version of my resume. It has
anchors (aka fragments) to jump to sections of the resume. Those work
when I specify a URL with the fragment in the command line to load
Firefox. There's nothing but simple text in the HTML code.

VanguardLH wrote:

> I tested using a local file set for a web version of my resume. It has
> anchors (aka fragments) to jump to sections of the resume. Those work
> when I specify a URL with the fragment in the command line to load
> Firefox.

If you drag from the firefox addr bar to e.g. the desktop to create a
windows shortcut, does that launch to the anchor position? That's the
only part of all this which doesn't work for me ...

Andy,

> I can repeat it here, but it seems to be a windows issue, not a firefox
> issue?

How did you get to that conclusion ?

> My shortcut includes my #anchor in the URL, but the firefox address bar
> doesn't show the #anchor once launched

Same here. I have no idea where the anchour gets dropped though.

> if I manually add the #anchor inside firefox and re-load, it works and
> jumps to the relevant point in the document.

Hmm... I see where you got the "its an OS problem" idea from.

As a check I just wrote a bach file to start firefox and gave it the
"file://" URL as a commandline parameter. It opens the local file and jumps
to the anchour.

IOW, it seems to support your "OS problem" idea. No idea what to do about
it though ...

Regards,
Rudy Wieser

R.Wieser wrote:

> I just wrote a bach file to start firefox and gave it the
> "file://" URL as a commandline parameter. It opens the local file and jumps
> to the anchour.
>
> IOW, it seems to support your "OS problem" idea. No idea what to do about
> it though ...

compare firefox behaviour to chrome/edge?

try wrapping stuff in quotes?

dunno ...

Andy Burns <usenet@andyburns.uk> wrote:

> VanguardLH wrote:
>
>> I tested using a local file set for a web version of my resume. It has
>> anchors (aka fragments) to jump to sections of the resume. Those work
>> when I specify a URL with the fragment in the command line to load
>> Firefox.
>
> If you drag from the firefox addr bar to e.g. the desktop to create a
> windows shortcut, does that launch to the anchor position? That's the
> only part of all this which doesn't work for me ...

When I run:

"<path>\firefox.exe" file:///C:/Users/.../resume.html#EDUCATION

the #fragment works. Firefox is doing the URL parsing. When I drag the
URL with #fragment to the Windows desktop to create a shortcut,
firefox.exe is not specified, just the URL of:

file:///C:/Users/.../resume.html#EDUCATION

That means double-clicking on the URL has Windows determine to which
handler the URL string gets passed. However, Windows uses a sneaky
trick in loading the default URL handler. It first loads its own
Internet Browser (no, not Internet Explorer) to then determine which URL
handler is the default.

I only came across the hidden Internet Browser program when I somehow
change the default from Firefox to Internet Browser wondering what the
hell was the latter.

Default apps -> Choose default apps by file type -> .url

It will show "Internet Browser". I don't remember how I changed it to
Firefox. My guess is I used Nirsoft's Filetype Viewer, selected .URL
(name is InternetShortcut), which shows 3 actions on the filetype:

Open "C:\Windows\System32\rundll32.exe" "C:\Windows\System32\ieframe.dll",OpenURL %l
print
printto

I only showed the command for the Open action. Notice it runs
rundll32.exe to load ieframe.dll to its OpenURL entry point while
passing the URL from the shortcut using the %L (not %1) substitution
variable. It is NOT directly running firefox.exe. ieframe's OpenURL
function decides what is the default handler specified for .url
filetypes. In Nirsoft, you can right-click on one of the actions to
open it in regedit. Open is defined at:

HKEY_CLASSES_ROOT\InternetShortcut\shell\Open\Command

and has the same command line as shown in Nirsoft. At first, I thought
# might be an illegal path (folder) or file name, but I tested by:

cd c:\temp
echo testing > test#me.txt
dir

dir lists the test#me.txt file, and I can open it in Notepad. So, it's
not # causing a problem in the filename. However, you're using the
file:/// scheme which specifies a file, and you don't have a file at
<path>\<file>#fragment. I would've thought you'd get a "file not found"
error, but instead the legitimate portion of the file path gets passed
by Internet Browser to the default handler (Firefox).

Instead of using a .url shortcut, what if you use a .lnk shortcut. It's
target would specify:

<path>\firefox.exe file:///c:/folder/file.htm#foobar

Then the shortcut is a .lnk file that runs a program to open the file
while including the #fragment substring. When I use a .lnk shortcut to
run Firefox and give the file with anchor, the web page opens to that
anchor. Instead of the .url shortcut passing the string to Internet
Browser which is rundll32 running the OpenURL function in ieframe.dll,
the .lnk shortcut directly runs Firefox.

Dragging from the web browser address bar to the Windows desktop creates
a .url shortcut. You want to create a .lnk shortcut. .lnk shortcuts
are to local files (or to registry-defined objects) while .url shortcuts
are to remote files.

For example, I want to assign a particular icon to a URL, but the .url
shortcuts all get the icon from the default web browser. Say I have a
shortcut that points to boatloadpuzzles.com for crosswords. I'd rather
assign a crossword-looking icon to that shortcut. Can't edit the icon
for a .url shortcut. I can change the icon in a .lnk shortcut. A lot
of URL shortcuts to different places all have the same icon, so they are
less distinguisable from each other. I have to read the text added to
the shortcut. With .lnk shortcuts, I could use a different icon image
for every .lnk shortcut. Easy for me to differentiate a shortcut to
Boatload crosswords from local weather from Google voice from Gmail from
Hotmail and so on. I can specify which icon to use for each URL
shortcut just like I can for icons of program shortcuts. A slew of
Firefox icons on my Windows desktop or in toolbars in the Taskbar looks
like a mess making me read their titles to see which goes where.

VanguardLH wrote:

> When I run:
>
> "<path>\firefox.exe" file:///C:/Users/.../resume.html#EDUCATION
>
> the #fragment works. Firefox is doing the URL parsing. When I drag the
> URL with #fragment to the Windows desktop to create a shortcut,
> firefox.exe is not specified, just the URL of:
>
> file:///C:/Users/.../resume.html#EDUCATION

Yes, I noticed that, but going to prooperties of the shortcut let me add
back #anchor

> That means double-clicking on the URL has Windows determine to which
> handler the URL string gets passed. However, Windows uses a sneaky
> trick in loading the default URL handler. It first loads its own
> Internet Browser (no, not Internet Explorer) to then determine which URL
> handler is the default.

the shellex handler for .url files seems to get bounced through
@%systemroot%\system32\ieframe.dll,-34560

I've not looked any deeper than that.

> I only came across the hidden Internet Browser program when I somehow
> change the default from Firefox to Internet Browser wondering what the
> hell was the latter.
>
> Default apps -> Choose default apps by file type -> .url
>
> It will show "Internet Browser". I don't remember how I changed it to
> Firefox. My guess is I used Nirsoft's Filetype Viewer, selected .URL
> (name is InternetShortcut), which shows 3 actions on the filetype:
>
> Open "C:\Windows\System32\rundll32.exe" "C:\Windows\System32\ieframe.dll",OpenURL %l
> print
> printto

ok, yes similar to what I saw, the %1 ought to be the full URL including
anchor though?

> I only showed the command for the Open action. Notice it runs
> rundll32.exe to load ieframe.dll to its OpenURL entry point while
> passing the URL from the shortcut using the %L (not %1) substitution
> variable. It is NOT directly running firefox.exe. ieframe's OpenURL
> function decides what is the default handler specified for .url
> filetypes. In Nirsoft, you can right-click on one of the actions to
> open it in regedit. Open is defined at:
>
> HKEY_CLASSES_ROOT\InternetShortcut\shell\Open\Command
>
> and has the same command line as shown in Nirsoft. At first, I thought
> # might be an illegal path (folder) or file name, but I tested by:
>
> cd c:\temp
> echo testing > test#me.txt
> dir
>
> dir lists the test#me.txt file, and I can open it in Notepad. So, it's
> not # causing a problem in the filename. However, you're using the
> file:/// scheme which specifies a file, and you don't have a file at
> <path>\<file>#fragment. I would've thought you'd get a "file not found"
> error, but instead the legitimate portion of the file path gets passed
> by Internet Browser to the default handler (Firefox).
>
> Instead of using a .url shortcut, what if you use a .lnk shortcut. It's
> target would specify:
>
> <path>\firefox.exe file:///c:/folder/file.htm#foobar
>
> Then the shortcut is a .lnk file that runs a program to open the file
> while including the #fragment substring. When I use a .lnk shortcut to
> run Firefox and give the file with anchor, the web page opens to that
> anchor. Instead of the .url shortcut passing the string to Internet
> Browser which is rundll32 running the OpenURL function in ieframe.dll,
> the .lnk shortcut directly runs Firefox.
>
> Dragging from the web browser address bar to the Windows desktop creates
> a .url shortcut. You want to create a .lnk shortcut. .lnk shortcuts
> are to local files (or to registry-defined objects) while .url shortcuts
> are to remote files.
>
> For example, I want to assign a particular icon to a URL, but the .url
> shortcuts all get the icon from the default web browser. Say I have a
> shortcut that points to boatloadpuzzles.com for crosswords. I'd rather
> assign a crossword-looking icon to that shortcut. Can't edit the icon
> for a .url shortcut. I can change the icon in a .lnk shortcut. A lot
> of URL shortcuts to different places all have the same icon, so they are
> less distinguisable from each other. I have to read the text added to
> the shortcut. With .lnk shortcuts, I could use a different icon image
> for every .lnk shortcut. Easy for me to differentiate a shortcut to
> Boatload crosswords from local weather from Google voice from Gmail from
> Hotmail and so on. I can specify which icon to use for each URL
> shortcut just like I can for icons of program shortcuts. A slew of
> Firefox icons on my Windows desktop or in toolbars in the Taskbar looks
> like a mess making me read their titles to see which goes where.

Andy,

> compare firefox behaviour to chrome/edge?

Whats that "chrome/edge" you're talking about ? :-) (can't test what I
don't have)

> try wrapping stuff in quotes?

An URL links "url:" property ? All of it ?

Just did, and it trashed the contents of the link (did not expect that btw).

I could ofcourse blindly(!) try to quote random-ish parts of it, but thats
what I tried to forgo ...

Regards,
Rudy Wieser

On Sat, 6 Jan 2024 10:22:48 +0100, R.Wieser wrote:
> I've got a file:///c:/folder/file.htm#foobar link, which opens, in FF v52,
> the local file as expected. Wat it /doesn't/ do however is to go to the
> "foobar" anchour (which exists, and can be jumped to using the in-page
> "menu").

What is the anchor in file.htm: is it foobar or some form containing
one or more capital letters? I'll bet it's the latter.

The _file_ is looked up through Windows, and therefore is not case
sensitive.

The _anchor_ is looked up by the browser directly, and therefore it
_is_ case sensitive. I've seen this in both Firefox and Chrome when I
mistyped a file:-type link with an anchor. It _should_ be true on all
browsers, and I'd be surprised if there were any important
exceptions.

--
Stan Brown, Tehachapi, California, USA https://BrownMath.com/
Shikata ga nai...

Stan,

> What is the anchor in file.htm: is it foobar or some form
> containing one or more capital letters? I'll bet it's the latter.
>
> The _file_ is looked up through Windows, and therefore is
> not case sensitive.

How much did I you lose by betting on it ? :-p

FYI, the URL shortcut was created by drag-and-dropping the in-page "menu"
link onto my desktop. And yes, it's the same anchour string as it appears
in the in-page "menu" (which works).

Also, as mentioned in a later post, I created a batchfile to start FF and
provided it the (quoted) URL as a parameter. That one works (jumps to the
anchour).

Regards,
Rudy Wieser

> I've got a file:///c:/folder/file.htm#foobar link, which opens, in FF v52,
> the local file as expected. Wat it /doesn't/ do however is to go to the
> "foobar" anchour (which exists, and can be jumped to using the in-page
> "menu").

I just thought of drag-and-dropping the same link from the origional webpage
to the desktop (resulting in a https:/// URL shortcut), and got the same
problem : it opens the webpage, but doesn't want to jump to the anchour.

IOW, its not just a file:/// protocol problem.

Regards,
Rudy Wieser