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

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@guest271314

You just have to decide what protocol you want to load the PDF from. Then use the appropriate approach, depending on the protocol you want to launch the new window from.

A PDF, on Chrome, is solely ever loaded into PDFJS. In the standard browser chrome, this is rendered as a file: schema-prefixed URI. In the ECMAScript console, it’s rendered in the title bar as a chrome-extension: URI. Perhaps you’re indeed correct to focus on this, because chrome-extension: URIs don’t appear to permit cross-origin invocations either.

@guest271314

using a shell script

Thanks, but that just uses the standard browser chrome. It also breaks PDFJS, which is another bug I can’t be bothered to report (yet):

google-chrome-canary --window-size=600,400 --password-store=basic 'file:///home/RokeJulianLockhart/Documents/@%7B'Name'='Common'%7D%23.dir/@%7B'Name'='Curriculum%20Vit%C3%A6'%7D%23.PDF'
Fontconfig error: Cannot load default config file: No such file: (null)
Created TensorFlow Lite XNNPACK delegate for CPU.
Attempting to use a delegate that only supports static-sized tensors with a graph that has dynamic-sized tensors (tensor#-1 is a dynamic-sized tensor).
[783620:783620:0319/161038.432379:ERROR:ui/gl/gl_surface_presentation_helper.cc:260] GetVSyncParametersIfAvailable() failed for 1 times!
[783620:783620:0319/161114.505561:ERROR:ui/gl/gl_surface_presentation_helper.cc:260] GetVSyncParametersIfAvailable() failed for 2 times!
[783620:783620:0319/161116.821150:ERROR:ui/gl/gl_surface_presentation_helper.cc:260] GetVSyncParametersIfAvailable() failed for 3 times!
[783560:783591:0319/161133.379902:ERROR:content/browser/browser_main_loop.cc:278] GLib: g_main_context_pop_thread_default: assertion 'stack != NULL' failed

Just reloading the page remediates it. How ridiculous.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@rokejulianlockhart

In the standard browser chrome, this is rendered as a file: schema-prefixed URI.

@guest271314, you’d put me on the correct track! I’ve ascertained the solution for google-chrome-canary-136.0.7076.0-1.x86_64, too! One merely needs to invoke the console in a verbatim “file://” URI for it to not be cross-origin!

1. 

2. 

Is this what you meant? Irrespective, thank you for the assistance!

[guest271314]

A PDF, on Chrome, is solely ever loaded into PDFJS. In the standard browser chrome, this is rendered as a file: schema-prefixed URI.

It’s not clear to me what you are really trying to do.

I can’t reproduce the issues you are having. Perhaps because it’s not clear what you are trying to do, to me.

In the ECMAScript console

There is no such thing. ECMA-262 doesn’t specify console, or I/O whatsoever for JavaScript.

it’s rendered in the title bar as a chrome-extension: URI. Perhaps you’re indeed correct to focus on this, because chrome-extension: URIs don’t appear to permit cross-origin invocations either.

Again, not clear what you are really trying to do.

[guest271314]

Is this what you meant? Irrespective, thank you for the assistance!

That’s one way, I guess. Your requirements keep changing and adding stuff.

No worries.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@guest271314

In the ECMAScript console

There is no such thing. ECMA-262 doesn’t specify console, or I/O whatsoever for JavaScript.

…the “Web Console”, for JS:

---

@guest271314

Your requirements keep changing and adding stuff.

My sole requirement is to invoke a window using the JS window.open API for a PDF file, with minimal browser chrome. I have repeatedly stated this. It cannot feasibly be more specific. I have provided screenshots and programmatic references regardless.

Luckily, I’ve already achieved this.

[guest271314]

@rokejulianlockhart

…the “Web Console”, for JS:

Yeah, ECMA-262 does not specify DevTools console or Firefox’s “Web Console”. ECMA-262 does not specify reading stdin or writing to stdout at all. The closest we get right now, officially, is import and import().

My sole requirement is to invoke a window using the JS window.open

You’ve got a shell script in this thread somewhere.

Luckily, I’ve already achieved this.

Great!

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@guest271314

@rokejulianlockhart

…the “Web Console”, for JS:

Yeah, ECMA-262 does not specify DevTools console or Firefox’s “Web Console”. ECMA-262 does not specify reading stdin or writing to stdout at all. The closest we get right now, officially, is import and import().

@guest271314, that explains the discrepancy. I apologise. Perhaps I should be calling this JS, as a superset of the ECMAScript definiton? Thank you, again.

[guest271314]

Oracle Corporation own the term “JavaScript” per their U.S> P.T.O. issuance, for what that’s worth. Deno is officially challenging that corporate “ownership” of the term.

ECMA-262 doesn’t spell out how to read STDIN or write to STDOUT, that is, console.

WHATWG does have a Console standard. How that behaves is different from runtime to runtime, or engine to engine.

If you try to write to STDIN using half a dozen different JavaScript engines or runtimes you might wind up writing that code half a dozen different ways. Some engines don’t have a way to read STDIN, such as SerenityOS’s LibJS js. Sometimes you can write similar code for different engines or runtimes to read STDIN or write to STDOUT - rarely if at all will the behaviour (“implementation details”) be the same.

This is what I had to do to read STDIN to Mozilla’s SpiderMonkey js shell native-messaging-spidermonkey-shell/nm_spidermonkey.js at main · guest271314/native-messaging-spidermonkey-shell · GitHub. Character by character processing by hand to read STDIN from Native Messaging client (the browser)

  // Call readline() N times to catch `\r\n\r\n"` from 2d port.postMessage()
  let stdin;
  while (true) {
    stdin = readline();
    if (stdin !== null) {
      break;
    }
  }
  
  let data = `${stdin}`.replace(/[\r\n]+|\\x([0-9A-Fa-f]{2,4})/gu, "")
    .replace(/[^A-Za-z0-9\s\[,\]\{\}:_"]+/igu, "")
    .replace(/^"rnrn/gu, "")
    .replace(/^[#\r\n\}_]+(?=\[)/gu, "")
    .replace(/^"(?=["\{]+)|^"(?!"$)/gu, "") 
    .replace(/^\[(?=\[(?!.*\]{2}$))/gu, "")
    .replace(/^\{(?!\}|.+\}$)/gu, "")
    .replace(/^[0-9A-Z]+(?=[\[\{"])/igu, "") 
    .replace(/^[\]\}](?=\[)/i, "")
    .trimStart().trim();
  // https://stackoverflow.com/a/52434176
  // let previous = redirect("length.txt");
  // putstr(data.length);
  // redirect(previous); // restore the redirection to stdout
  // os.file.writeTypedArrayToFile("input.txt", encodeMessage(data));
  return encodeMessage(data);

Compare QuickJS

function getMessage() {
  const header = new Uint32Array(1);
  std.in.read(header.buffer, 0, 4);
  const output = new Uint8Array(header[0]);
  std.in.read(output.buffer, 0, output.length);
  return output;
}

It’s not in ECMA-262, the implementation can be conformant without a console or capability to write to a TTY or non-TTY or read from a TTY, non-TTY, file descriptor.

[guest271314]

@guest271314

rarely if at all will the behaviour (“implementation details”) be the same.

A modest effort to write the same runtime agnostic code to read STDIN and write to STDOUT for different JavaScript runtimes NativeMessagingHosts/nm_host.js at main · guest271314/NativeMessagingHosts · GitHub.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

1. @guest271314

   ECMA-262 doesn’t spell out how to read STDIN or write to STDOUT, that is, console.

2. @guest271314

   It’s not in ECMA-262, the implementation can be conformant without a console or capability to write to a TTY or non-TTY or read from a TTY, non-TTY, file descriptor.

@guest271314, indeed – when I mentioned ECMAS in the title, I was referring to the window.open() and share() APIs.

The console was merely my chosen method of interaction with the browser’s ECMAS engine. I probably should have tested whether the commands would work in an .HTML file’s ` tag, now that I think of it, though.

---

@guest271314

WHATWG does have a Console standard.

I wasn’t aware. Appears to be console.spec.whatwg.org. ^[1] Gosh, they really have standardised everything!

---

1. github.com/whatwg/console/tree/6960f44889f8dc9346e5a0e8981af22d5104df24 ↩︎

[guest271314]

@guest271314, indeed – when I mentioned ECMAS in the title, I was referring to the window.open() and share() APIs.

Those are not ECMAScript interfaces, either.

They are either spelled out by W3C, WICG, or WHATWG.

Gosh, they really have standardised everything !

No. Not everything. For example, reading STDIN and writing to STDOUT is not specified by those bodies. I think CommonJS includes writing to STDOUT and reading STDIN in their specification. A gist I wrote describing the omission JavaScript Standard Input/Output: Unspecified · GitHub.

[rokejulianlockhart (Mr. Beedell, Roke Julian Lockhart (RJLB))]

@guest271314

They are either spelled out by W3C, WICG, or WHATWG.

@guest271314, so, what Oracle brands as JavaScript is actually a combination of > 4 standards?

[guest271314]

No. I think the story goes something like Bendan Eich created JavaScript in 10 days Popularity – Brendan Eich. Through acquisition Oracle Corporation acquired the name and code. Though clearly Oracle Corporation doesn’t really use JavaScript in the “stream of commerce”, which is generally a requirement in the IPR game. Here’s Deno’s take Deno v. Oracle: Canceling the JavaScript Trademark on why they decided to rep JavaScript. Another resource History and evolution of JavaScript.

In the browser there are various “stakeholders” and technologies that might not be spelled out in ECMA-262 though use a JavaScript interface. Console is one of them.