You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Port messages with Blob objects are being filtered out in Firefox 116; Blob object is unreachable within GM.xmlHttpRequest with responseType: "blob"#3166
Open
SebastianSimon opened this issue
Jun 14, 2023
· 2 comments
Since Firefox Nightly 116, GM.xmlHttpRequest({ responseType: "blob",…}) never calls the onload handler. Other handlers like onprogress are always correctly called. If I change responseType to one of the other available types, onload is correctly called. If I use Firefox Beta 115, onload is correctly called for responseType: "blob". No errors are shown in any console.
When debugging the extension, the function xhrEventHandler in src/bg/on-user-script-xhr.js is actually being called with all relevant events, including the call where event.type === "load". It turns out, if you set a breakpoint before port.postMessage({ 'src': src, 'type': event.type, 'responseState': responseState });, then execute responseState.response = null; in the console, then the onload handler is being executed. The issue appears to be that port messages that contain blobs are being ignored or somehow filtered out, likely due to security reasons. This also affects the final readystatechange event.
The question now is: can GreaseMonkey do something about this—perhaps provide a workaround—, or is this exclusively a Firefox issue?
Click the “More information...” link on the example site
Test userscript
// ==UserScript==// @name Test: XHR Blob on link click// @include https://example.com/// @run-at document-start// @grant GM.xmlHttpRequest// ==/UserScript==(()=>{"use strict";((main)=>(document.readyState==="loading"
? addEventListener("DOMContentLoaded",main)
: main()))(()=>{document.querySelector("a:link").addEventListener("click",(event)=>{event.preventDefault();console.log("clicked");GM.xmlHttpRequest({method: "GET",url: event.target.href,responseType: "blob",onprogress(...args){console.log("progressed");// This is always logged.},onload(...args){console.log("loaded");// This is always logged in Firefox <= 115, but never in Firefox Nightly 116.}});});});})();
Actual result
"clicked" and "progressed" are always logged. "loaded" is never logged.
Desired result
"loaded" is correctly logged.
The text was updated successfully, but these errors were encountered:
SebastianSimon
changed the title
onload is never called within GM.xmlHttpRequest with responseType: "blob" in Firefox Nightly 116.0a1
Port messages with Blob objects are being filtered out in Firefox 116; Blob object is unreachable within GM.xmlHttpRequest with responseType: "blob"Jun 14, 2023
Since Firefox Nightly 116,
GM.xmlHttpRequest({ responseType: "blob",
…})
never calls theonload
handler. Other handlers likeonprogress
are always correctly called. If I changeresponseType
to one of the other available types,onload
is correctly called. If I use Firefox Beta 115,onload
is correctly called forresponseType: "blob"
. No errors are shown in any console.When debugging the extension, the function
xhrEventHandler
insrc/bg/on-user-script-xhr.js
is actually being called with all relevant events, including the call whereevent.type === "load"
. It turns out, if you set a breakpoint beforeport.postMessage({ 'src': src, 'type': event.type, 'responseState': responseState });
, then executeresponseState.response = null;
in the console, then theonload
handler is being executed. The issue appears to be that port messages that contain blobs are being ignored or somehow filtered out, likely due to security reasons. This also affects the finalreadystatechange
event.The question now is: can GreaseMonkey do something about this—perhaps provide a workaround—, or is this exclusively a Firefox issue?
Steps to reproduce
Test userscript
Actual result
"clicked"
and"progressed"
are always logged."loaded"
is never logged.Desired result
"loaded"
is correctly logged.The text was updated successfully, but these errors were encountered: