The usage of SharedArrayBuffer causes an error: Uncaught ReferenceError: SharedArrayBuffer is not defined on Chrome 92. Why is this? How can I solve?
SharedArrayBuffer on Chrome desktop has been available for free until Chrome 91, but after 92, it requires a special state called "cross-origin isolation" aligned with Firefox and Android Chrome. To enable the state, you must send two security headers Cross-Origin-Embedder-Policy: require-corp and Cross-Origin-Opener-Policy: same-origin.
The discovery of Spectre caused all browsers to disable SharedArrayBuffer but Chrome desktop could enable it again using the proprietary Site Isolation. Chrome 92 is the version it shifted to the standardized approach.
As mentioned above, applying the two headers and enable "cross-origin isolation" is the way to go, but it may take you a while to set it up. As an escape-hatch, you can request an origin trial to allowlist your site to continue using SharedArrayBuffer without cross-origin isolation at least until Chrome 96.
To learn more about cross-origin isolation, read:
SharedArrayBuffer updates in Android Chrome 88 and Desktop Chrome 92
Making your website "cross-origin isolated" using COOP and COEP
Why you need "cross-origin isolated" for powerful features
A guide to enable cross-origin isolation
Related
I have an angular app sending http post request to Azure apim.
It works fine in Chrome and FF but fails in IE 11. I have looked at other solutions but nothing worked.
CORS policy is set to allow all header and all methods.
I am getting this kind of error in IE network TAB.
SCRIPT7002: XMLHttpRequest: Network Error 0x2efd, Could not complete the operation due to error 00002efd.
I see GET request with 200 instead of POST, also there is nothing in the request and response headers.
Apparently it is a Windows 10 bug in the HTTP stack that is now solved in Windows 10 version 1803 (April 2018). So normally this problem will disappear over time for people/companies using auto updates of Windows, used Windows 10 versions WorldWide.
We tested this on an older and newer version of Windows 10 and it is indeed solved.
Some workaround could be:
1.Disable HTTP/2 for IE and Edge and use HTTPS (server side change).
2.Use GET (if possible)
3.Do PUT also has this problem?
4.Do some retries if no response headers are returned
5.Accept that IE/Edge users will be punished ;-)
One user is getting this error when trying to initiate a call with APIRTC on Chrome. I am assuming it is some kind of security restriction on their chrome installation. I am also assuming other computers at the same facility will likely have the same problem.
Does anyone know what this error indicates and what setting is required in chrome or the code to fix it?
UserMediaError triggered by webRTCClient.call. Error is istrusted:false.
According to MDN the correct approach is to send the header:
Link: </images/big.jpeg>; rel=prefetch
So my express syntax is:
res.header('Link', '</images/big.jpeg>; rel=prefetch');
and I see it land in my browser as:
Link:</images/big.jpeg>; rel=prefetch
But chrome never attempts to download the image.. The meta and link approaches work fine..
Am I setting the header wrong or is the browser failing to process the header value?
UDPATE: Okay so it looks like I'm doing things right but Chrome 43 & Chromium 43 on Linux/Ubuntu doesn't have support for this yet. This is working fine in Firefox 38..
Could it be that Chromium is just not showing the prefetching in the Network tab?
UPDATE 2: So it does look like Chrome/Chromium is hiding the file transfers from the Network tab. If someone can confirm this I'd appreciate it..
To set prefetch for one file in Express 4+..
res.set('Link', '<static/js/file1.js>; rel=prefetch');
For multiple files.
res.set('Link', '<static/js/file1.js>; rel=prefetch, <static/js/file2.js>; rel=prefetch');
Do NOT attempt to test this in Chrome, Chrome will lie to you and show it as not working if you investigate under Network tab. Always test with Firefox.
You can see me implementing this in a larger project in context here.
I have developed a Google Chrome extensions that uses YouTube Data API v2. My permission field in the manifest looks like this, because the script is injected in pages under youtube.com and I also need access to tabs:
"permissions": ["tabs", "*://*.youtube.com/*"]
This also works when I do a request to YouTube Data API v2 because the request is done to http://gdata.youtube.com/, so it is the same domain. But now I am migrating to YouTube Data API v3, and the requests must be done to http://www.googleapis.com/youtube/v3/ (note HTTPS instead of HTTP also). However, surprisingly, my requests are working perfectly without adding any new permission.
I know, I am asking something that doesn't seem to be a problem, but personally I consider any behavior that I don't understand in my software a problem. Why does this happen? Am I not supposed to add a permission such as "*://*.googleapis.com/*" in order for my XMLHttpRequest requests to the API to work?
I also have some king of guess about this: HTTP Access Control headers. My requests do send a Origin header with value chrome-extension://myExtensionId. And the answer from the API also contains the following header:
Access-Control-Allow-Origin: chrome-extension://myExtensionId
But could this be the reason Chrome is allowing me to do a cross-origin XMLHttpRequest without any extra permission defined in the manifest? Not sure, and apparently this is not documented anywhere in Google APIs, YouTube Data API v3 or Chrome Extensions developer documentation.
If Chrome does not find the permission in the manifest, it treats a request as a normal request. This means that a request will still succeed when the right CORS headers are set. Otherwise, a request will fail because of the same origin policy.
The Google API JavaScript library explicitly mentions support for CORS:
Making a request: Option 3
Google APIs support CORS. Please visit the CORS page for more information on using CORS to make requests.
If possible, I still recommend adding the permission to the manifest file. For simple requests, this does not bring any advantages. For non-simple requests, this will half the number of requests: Non-simple requests are always preceeded by a preflight (OPTIONS) request which checks if the client is permitted to access the source.
By adding the permission to the manifest file, Chrome will not fall back to CORS, and always use one network request to complete the request. Great!
However... you might think again if you're the author of an already-deployed extension. When new origin permissions are added to the manifest file, the extension will be disabled until the user approves the extension. The dialog box shows "Remove extension" and "Enable" next to each other, so there's a chance of loosing the user.
If you wish, you can overcome this problem by using an optional permission, activated at the options page. Clearly explain in layman language that the option will improve the speed of the extension, and don't forget to mention that additional permissions will be requested.
"NaCl is currently only turned on by default for applications/extensions from the Chrome Webstore, or unpacked extensions for development purposes." - the Internet
Yet I can't seem to be able to use NaCl from an unpacked extension. (I did not try the Web Store.)
I have a really simple test extension which has the following in its background.js:
function clicked() {
var testNaclElement = document.createElement("embed");
testNaclElement.setAttribute("type","application/x-nacl");
testNaclElement.setAttribute("width",0);
testNaclElement.setAttribute("height",0);
document.body.appendChild(testNaclElement);
alert(testNaclElement.postMessage?true:false);
document.body.removeChild(testNaclElement);
}
chrome.browserAction.onClicked.addListener(updateIcon);
updateIcon();
This extension reports true when the NaCl is enabled in chrome://flags, but when NaCl is disabled in chrome://flags (which is the default) it reports false.
I expected it to report true.
What am I missing?
Update:
It seems that inventing my own detection code not such a good idea after all.
If I create and install an unpacked chrome webapp that points to url X, then NaCl will work on that page, but this detection code will still report false, while the very same code reports true when on a normal webpage with NaCl enabled in chrome://flags.
BUT if create an extension (not a chrome webapp) that uses NaCl in an iFrame which points to url X, then NaCl will not work in it.
BUT if I create a webapp that points to url X and an extension that uses url X in an iFrame, then both will work if installed at the same time.
Update2:
If I actually include the nmf and nexe in the extension, then it works.
Update3:
nexe needn't be included in the extension.
Chrome requires nmf location to belong to extension. Empty nmf attribute doesn't have this property.
a better way to detect if a NaCl module is loaded is to use progress events. see https://developers.google.com/native-client/pepper16/devguide/coding/progress-events for the enumeration of events and an example.
about the url X -- i don't think events propagate pass iframes if the iframe's URL and the container's URL domains differ -- and any enabling of NaCl in the web store or unpacked extensions corresponds to an URL (possibly with a special proto-spec; i don't know the details), so that might explain the various combinations that you're seeing. it probably also depend on how you specified the URL set in the webapp manifest.
the code's testNaclElement lack a src= attribute/value pair. it's been a while since i looked at the NaCl plugin's code, but that might also cause problems.