How to perform arbitrary commands file URIs via ECMAScript in FF, as a user?

Problem

I want to capture a screenshot of a file:// URI with minimal window decorations for the undermentioned:

Consequently, I have attempted to:

  1. Invoke a bookmark containing javascript:window.open(location.href, "detab", "toolbar=0"); window.close() on the URI, to no avail.

  2. Hardcode the URI like javascript:window.open("file:///home/RokeJulianLockhart/Downloads/@%7B'Name'='Curriculum%20Vit%C3%A6'%7D%23.PDF", "detab", "toolbar=0"); window.close(), to no avail.

    1. Enter a custom HTML file:

    2. Invoke it in the console (to no avail):

      22:15:05.436 Uncaught Error: Access to 'file:///home/RokeJulianLockhart/Downloads/@%7B'Name'='Curriculum%20Vit%C3%A6'%7D%23.PDF' from script denied
          <anonymous> debugger eval code:1
      debugger eval code:1:8
      
  3. Provide the aforementioned as a CLI argument, [1] to no avail.

How can I accomplish this?

Comparison

This executes in google-chrome-canary-136.0.7069.0-1.x86_64:

All I needed to do was type “allow pasting”:

However, it doesn’t invoke a minimal window, so it doesn’t provide what I want for this circumstance.


  1. superuser.com/revisions/157324/1 ↩︎

1 Like

If you opne DevTools, then click the three dots for settings, then click “Settings” you can check “Take screenshot of the entire page” option.

@guest231314, I don’t wish to capture a screenshot of merely the webpage. Rather, I wish to spawn a basic window like the undermentioned:

…However, for a PDFJS window of a file: URI.

This works on file: protocol on Nightly 138

window.open(location.href, "_blank", "left=100,top=100,width=320,height=320")
1 Like

If the environment is a Chromium-based browser I don’t think you’ll face that same issue re file: protocol and window.open().

firefox-136.0.1-1.fc41.x86_64

@guest271314, thanks! That’s clever. Unfortunately, its permission denial is identical, whether invoked from an HTTP: or PDFJS file: URI:

google-chrome-canary-136.0.7070.0-1.x86_64

On a data: URI, the consequence is identical, unfortunately:

However, invoking it in a PDF tab executes without failure:

…but merely generates another tab, strangely:

…(albeit as before):

Works for me on Firefox Nightly 138.0a1 (2025-03-16) (64-bit) and Chromium Version 136.0.7073.0 (Developer Build) (64-bit), both from today.

In Nightly I always set security.fileuri.strict_origin_policy to false. On Chromium I have several command line switches set, including --allow-file-access-from-files.

Looks like your screenshot is of a chrome-extension: protocol URL, not a file: URL.

You can set relevant Web extension permissions is manifest.json, .e.g.,

"host_permissions": [
    "<all_urls>",
    "file:///*"
  ],


and so forth.

If you are really on a chrome-extension: URL - and it’s your unpacked extension - you can set windows permissions use chrome.windows.create() with options, among other approaches.

I think Firefox implements windows Web extension API, too.

@guest271314, that didn’t modify the beheaviour for me in firefox-136.0.1-1.fc41.x86_64. Does it require a browser restart, or anything else unintuitive?


Unfortunately, this doesn’t matter much, since Chrome already allows the JS to run, it merely doesn’t interpret it correctly, because it creates a tab instead of a window (as aforementioned).


Where do you see that?



Those are HTML files. They need to be PDF files for this to apply. The code executes on HTML files – they’re my reference.

@guest271314, what do you refer to by “your unpacked extension” – what extension? How could I be on a chrome-extension-schema-prefixed URI when I see file in the omnibox, and I’m looking at the native PDFJS implementation? [1]


  1. github.com/mozilla/pdf.js/blob/d8b6f1138fdd83c2f48531753f3647be7c45e79b/README.md?plain=1#L37C1-L37C45 ↩︎

Some of your screenshots clearly shows the “chrome-extension:” protocol.

The MIME type or file type doesn’t matter.

Nightly

Set the appropriate window parameters, and use a blank target.

BTW this is about host environments, user agents, vendors’ specific implementations of DOM and to some extent Web API’s, not ECMAScript.

@guest271314, I had missed that. Those are the ones that are invoked in the PDFJS GUI, per stackoverflow.com/revisions/53870808/3. It’s merely PDFJS’s ID:

  1. How can I find the folder for chrome-extension://mhjfbmdgcfjbbpaeojofohoefgiehjai (the hidden “Chrome PDF viewer”)?

  2. It’s an internal component of Chrome.

I’d presume that the schema is the cause, but it’s not:



That works for HTML files, [1] but is blocked on the PDFJS GUI.


That’s in the thread title - “in FF”. Chrome was a comparison.


  1. stackoverflow.com/revisions/1574020/3 ↩︎

What I would do is get the source code of the extension and load the extension in Chrome as an unpacked extension on chrome://extensions. Then the folder will be wherever you downloaded the source folder to.

That works for HTML files, but is blocked on the PDFJS GUI.

We’ll, if you are using a Web extension, use another Web extension to override the former and do whatever you want.

I don’t know what you mean about PDFJS GUI.

The original question appeared to me about opening a local file on file: URL in a popup window.

You’ll have to dive in about:config and hack around to try to get Firefox to behave similar to Chrome, in various ways. And vice versa. Might be possible, might not be possible.

1 Like

@guest271314, a PDF file. These are treated specially: they are always invoked in the PDFJS GUI, which is included with Chrome and Firefox! Whether it’s an extension or not under-the-hood is an implementation detail, because it isn’t removable, and isn’t even exposed to the user as an extension. One of my previous SO citations explained this:

Consequently:

I’ll try that, if I’m able to. It might work, if it integrates with about:preferences#general:~:text=Applications when loaded like any normal extension:

I’m not sure about exactly what you’re trying to do specific to Firefox.

@guest271314, the aforementioned:

Summarily, I want window.open(location.href, "detab", "toolbar=0") to operate on file:// URIs for PDF files, like it does on HTML files (whether served via moz-extension:, about:, file, or https).

@guest271314, a PDF file. These are treated specially: they are always invoked in the PDFJS GUI, which is included with Chrome and Firefox ! Whether it’s an extension or not under-the-hood is an implementation detail, because it isn’t removable, and isn’t even exposed to the user as an extension. One of my previous SO citations explained this:

I don’t know who told you that. I do whatever i want on Chromium. By any means necessary.

Summarily, I want window.open(location.href, "detab", "toolbar=0") to operate on file:// URIs for PDF files, like it does on HTML files.

I demonstrated that is possible, above.

If you want to do that from arbitrary URL’s, file:, http:, whatever, then I would suggest writing an extension. Firefox tries to block all kinds of programmatic usages in DevTools.

@Guest271314, yeah:

However, I don’t know what you’ve done to your browser which enabled that, because the about:config preference didn’t.


I don’t. I can already do that, and it doesn’t require a WebExtension.


I’ve already cited my sources. It’s fact that Chrome and Firefox use PDFJS as their PDF renderer. You display it in your screenshot.