The include directive is not working in Firefox 68.0.2

[acebone]

Include has always been funky with this web-extension - In FF64 I can get it to include a file in the same directory, but it will not include that very same file if it's placed anywhere else ie. in a subfolder of the main file directory.

However with FF68.0.2 I can't include anything at all, and looking at the extensions page I get the errors shown in the attached screenshot

I'd be more than happy to assist in getting the extension to include as it should in all versions of FF. But I wouldn't know how to go about it.

[ggrossetie]

Hello @acebone, thanks for your report.

It seems that Firefox now throws a NetworkError when the extension is trying to read the content of the included file.
I found the following in the Firefox 65 release note:

XMLHttpRequest requests will now throw a NetworkError if the requested content type is a Blob, and the request method is not GET (bug 1502599).

https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/65

Not sure if it's related and/or if it's intented because we are using a GET request.
The code is:

var data = '';
var status = -1;
try {
  var xhr = new XMLHttpRequest();
  xhr.open('GET', path, false);
  xhr.addEventListener('load', function() {
    status = this.status;
    // status is 0 for local file mode (i.e., file://)
    if (status === 0 || status === 200) {
      data = this.responseText;
    }
  });
  xhr.overrideMimeType('text/plain');
  xhr.send();
}
catch (e) {
  throw $$($nesting, 'IOError').$new('Error reading file or directory: ' + path + '; reason: ' + e.message);
}
// assume that no data in local file mode means it doesn't exist
if (status === 404 || (status === 0 && !data)) {
  throw $$($nesting, 'IOError').$new('No such file or directory: ' + path);
}
return data;

And the following exception is thrown:

{
  "code": 19,
  "columnNumber": 0,
  "data": null,
  "filename": "moz-extension://cd380291-0789-b247-9c89-203d6aa6146d/js/vendor/asciidoctor.js",
  "lineNumber": 19999,
  "message": "A network error occurred.",
  "name": "NetworkError",
  "result": 2152923155
}

I tried to use a local HTTP server but I got the following error/warning:

Erreur dans les liens source : TypeError: NetworkError when attempting to fetch resource.
URL de la ressource : moz-extension://cd380291-0789-b247-9c89-203d6aa6146d/js/vendor/chartist.min.js
URL du lien source : chartist.min.js.map

So I'm not sure what is happening... but it's important to note that it's working fine in Chrome (with the same code).

[ggrossetie]

It's also working in Firefox 66 (on Linux).

[ggrossetie]

https://discourse.mozilla.org/t/a-network-error-occurred-thrown-when-using-xmlhttprequest-on-file-protocol-with-firefox-68/44259

[ggrossetie]

Apparently they blocked it for security reasons: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/68#Security so the include directive won't work when using the file:// protocol.

[ggrossetie]

@acebone You can try to change privacy.file_unique_origin to false in about:config, then restart Firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

[ggrossetie]

The complete procedure:

1. In a new tab, type or paste about:config in the address bar and press Enter/Return. Click the button promising to be careful or accepting the risk.
2. In the search box above the list, type or paste uniq and pause while the list is filtered
3. Double-click the privacy.file_unique_origin preference to switch the value from true (secure) to false (insecure)

[acebone]

I had a computer-crash and I've been reconstructing my setup on a new machine. I'll return with my results shortly

[gizzmojr]

68.0.2 (64-bit) for Ubuntu, the change to privacy.file_unique_origin was required to get my includes working again.

[ggrossetie]

Thanks @gizzmojr, I will add the procedure to the README 👍

[acebone]

@acebone You can try to change privacy.file_unique_origin to false in about:config, then restart Firefox and see if this can make a difference (please note that this makes you vulnerable to the described security problem though).

I'm now on FF 78.0.2 (ubuntu 19.10) and this doesn't work

(sry for the long delay in answering)

[ggrossetie]

I just did a quick test on 78.0.2 (Ubuntu 18.04) with the following document and it's working:

main.adoc

This repository contains samples.

include::../tip-version.adoc[]

tip-version.adoc

Please use the latest version.

Could you please provide a sample document to reproduce this with the error messages in the background page and/or in the main page (if any)?

[acebone]

= Test
include::file:///home/esm/Dropbox/Media-projects/xmind-lib/adoc/adoc-global-config.adoc[tags=config] 

No error message, but file is not included.

Trying to include a custom global config file (the file path is verified).

This line:

include::file:///home/esm/Dropbox/Media-projects/xmind-lib/adoc/adoc-global-config.adoc[tags=config]

gives this error:

Unresolved directive in scratchpad.adoc - include::file:///home/esm/Dropbox/Media-projects/xmind-lib/adoc/adoc-global-config.adoc[tags=config]

This line:

include::/home/esm/Dropbox/Media-projects/xmind-lib/adoc/adoc-global-config.adoc[tags=config]

gives this error:

Unresolved directive in scratchpad.adoc - include::/home/esm/Dropbox/Media-projects/xmind-lib/adoc/adoc-global-config.adoc[tags=config]

The following is working:

include::scratchpad2.adoc[]

[acebone]

[ggrossetie]

Not sure if it's a type but you need an empty line are the document title.
The following is not valid:

= Test
include::file:///path/to/doc.adoc[]

It should be:

= Test

include::file:///path/to/doc.adoc[]

Using an absolute path also works on my machine. What is the URL of the main document?
In my case, I'm doing:

Go to file:///path/to/dir/doc.adoc

doc.adoc

include::../include.adoc[] 

include::file:///path/to/include.adoc[]

include::/path/to/include.adoc[]

All of the above is working.

I see "Dropbox" in the path, maybe it interferes with the XMLHttpRequest?
Can you try to create a small reproduction case with two files in a simple directory structure. You could even create a GitHub repository so I can clone it and try to reproduce the issue on my machine.

[acebone]

I'm not using Dropbox actually, it's just a leftover from way back.

There is a problem with the include mechanism, but it's quite different from what I thought, so I am in the wrong bugreport-thread altogether. Sorry about that.

The problem seems to be, that I can only include files further down the filepath

Given the files

/home/esm/main1.adoc
/home/esm/include1.adoc

/home/esm/adtest/main2.adoc
/home/esm/adtest/include2.adoc

the main1.adoc will be able to include all the other files, but main2.adoc will only be able to include include2.adoc

I've set safe mode to 'unsafe'

The include-mechanism works as expected with commandline asciidoctor.

[ggrossetie]

There is a problem with the include mechanism, but it's quite different from what I thought, so I am in the wrong bugreport-thread altogether. Sorry about that.

No I think it's the same issue because it sounds like a restriction in the origin policy from Firefox.
Could you try to:

1. Go to about:config
2. Set security.fileuri.strict_origin_policy to false
3. Set privacy.file_unique_origin to false
4. Test
5. Restart the browser
6. Test

the main1.adoc will be able to include all the other files, but main2.adoc will only be able to include include2.adoc
I've set safe mode to 'unsafe'
The include-mechanism works as expected with commandline asciidoctor.

I'm 99% sure that this is a restriction in Firefox (not in Asciidoctor.js).

[acebone]

It works! Nice!

Perhaps leave a note about this in the readme or elsewhere?

Thanks for your patient help :)

[fbruetting]

I also ran into this, because I wanted to include global settings (from the main folder) in each chapter file (which are in their own folders), so that I can view those files on their own with the global confinguration. Is there a way without weakening Firefoxs security?

[sturtison]

Should we include this in the refresh of the README.adoc here #648 ?

FireFox is now at v113.2

[ggrossetie]

If my workaround is still working with the latest version, yes we should. Also, I think we should include the version of the browser (i.e., "workaround tested on Firefox 113.2)