unix `file:` urls don't work.

[Lazerbeak12345]

This config:

*
+file:///usr/share/doc/fish/index.html

Saves as this:

*
+usr/share/doc/fish/index.html

And doesn't allow the user to browse to the url file:///usr/share/doc/fish/index.html

Here's the Wikipedia article on the file: URI scheme and several common gotchas

[Lazerbeak12345]

Saving the file as:

*
+/usr/share/doc

Does not fix the problem either.

[proginosko]

Interesting. I'm not sure why that isn't working. What happens if you use the double-wildcard?

+**/usr/share/doc/fish/index.html

[Lazerbeak12345]

Sorry for the delay.

Just tried it. It didn't unblock it.

[proginosko]

What about this?

+usr/share/doc

You are using Google Chrome on a Unix/Linux system, correct?

Another question: If you deactivate the block and go to the URL file:///usr/share/doc/fish/index.html does the exact same URL appear in the browser address bar?

[Lazerbeak12345]

Sorry for any sort of confusion.

Here's what I have right now

*
+**/home/username
+**/usr/share/doc/fish/index.html

Followed by a few other urls.

Interestingly, the urls in username's home directory are accessible by that user.

Feels like a stop-gap, though as the next line doesn't work at all.

I'm using Version 1.34.81 Chromium: 97.0.4692.99 (Official Build) (64-bit) on Fedora Linux 35 (Workstation Edition)

[Lazerbeak12345]

Here's the exact url, after it gets blocked: chrome-extension://blaaajhemilngeeffpbfkdjjoefldkok/blocked.html?1&file:///usr/share/doc/lua

[Lazerbeak12345]

Interestingly, the "Allow Access to file urls" setting doesn't seem to change this.

[Lazerbeak12345]

When the extension is disabled, I can access the url correctly. Here's the content of the navigation bar: file:///usr/share/doc/lua/

[Lazerbeak12345]

Oh wait. That other bug might effect this. Let me try changing

*
+**/home/username
+**/usr/share/doc/fish/index.html

to

*
+file:///home/username
+file:///usr/share/doc/fish/index.html

yeah, no that didn't fix it.

EDIT wait a hot minute I've been testing multiple different urls. Let me test that again with this instead:

+file:///* (didn't work. also tried +file:///**)

[proginosko]

I have not been able to reproduce this problem. The latest version of LB (1.4) includes a diagnostic page that allows you to test a URL against your block sets. Go to the Options page, About tab, and click Open Diagnostics Page. Enter the URL that is getting (wrongly) blocked and click Test URL. Post the output here.

[Lazerbeak12345]

Input url: file:///usr/share/doc/fish/index.html#completion

Output text:

====== Block Set 1 (Whitelist)
BLOCK: file:///usr
ALLOW: -

====== Block Set 2 (Blacklist with time limit)
BLOCK: -

Ctrl+F on The whitelist option page shows that only this line contains file: +file:///**. This is followed and proceeded by a fairly large number of domains each prefixed with +. First line of the file is *

The second block set includes no mention of file.

(And yes, this does fail to open)

[proginosko]

Okay, so that confirms that it's Block Set 1 that's responsible for the file URL being blocked. What exactly is in your site list in Block Set 1? Also, please check that you don't have anything entered in the regular expression fields in the Advanced Options for Block Set 1.

[proginosko]

If you don't want to post the site list here, you can email it to me at leechblockng@proginosko.com instead. Even better, export your options to a text file and email that to me!

[Lazerbeak12345]

Email sent!

[Lazerbeak12345]

+FILE syntax now works!