1412114 - loadFrameScript doesn't work with blob: URLs

Status: RESOLVED DUPLICATE of bug 1415081

(Core :: DOM: Content Processes, defect, P2)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

STR:
  var b = new Blob(['console.log("test")'], { type: "text/javascript" });
  var u = URL.createObjectURL(b);
  var mm = gBrowser.selectedBrowser.messageManager;
  mm.loadFrameScript(u, false);

The same script as a data: URL works.  Some debugging shows the problem is in nsMessageManagerScriptExecutor::TryCacheLoadAndCompileScript at [1]: it's trying to read the script with blocking I/O and assumes that the Available method always returns the entire length.

With a Blob stream, this isn't the case; it's getting 0, probably due to the case at [2], and assumes the script is empty.

The context for this is bug 1376814, where I suggested loading our own XPCOM add-ons' frame scripts from blob: URLs, to avoid sandboxing problems.  Because of this bug that won't work, which means that reading the file into a string and passing it as a data: URL is the only other option for that use case.


[1] https://searchfox.org/mozilla-central/rev/dd47bee6468de7e1221b4d006342ad6b9813d0e5/dom/base/nsFrameMessageManager.cpp#1633

[2] https://searchfox.org/mozilla-central/rev/dd47bee6468de7e1221b4d006342ad6b9813d0e5/dom/file/ipc/IPCBlobInputStream.cpp#164

Comment 1

[Gabor Krizsanits (INACTIVE)]

Baku, do you think it's easy / worth to fix this? Or should we try to covert these blob URLs into data URLs instead (as a workaround in the workaround...)?

Comment 2

[Andrea Marchesini [:baku]]

Using Available() to know the length of the string is wrong for nsIAsyncInputStream.
Can we make try to make TryCacheLoadAndCompileScript() async? Let me think about it.

Comment 3

[Andrea Marchesini [:baku]]

Of course, the workaround of the workaround works. Just using FileReader.readAsDataURL() we can fix the problem.
Changing TryCacheLoadAndCompileScript() is a bit out of scope here.

Comment 4

[Andrea Marchesini [:baku]]

Actually, now this works. I fixed it in bug 1415081.