I'm testing out some audio worklet code by loading an example module from Github via AudioWorklet.addModule(githubUrl). However when I look at the network tab in developer settings I don't see a network request to Github. I know that it is making the request because it was giving a CORS error before I switched to using raw.githubusercontent address (now it is giving Uncaught (in promise) DOMException: The user aborted a request). I want to be able to inspect what the network call is returning so I can help diagnose the problem.
There seems to be a bug in Chrome which prevents the network request from being shown in the dev tools. I think it would be a good idea to file a bug for that.
For now you could just use Firefox. It shows the network request in the dev tools.
If you want to keep using Chrome you can proxy your request with fetch() to make it appear in the devtools.
Instead of calling addModule() directly ...
context.audioWorklet.addModule(url)
... you could fetch the source first and then wrap it into an object URL.
fetch(url)
.then((response) => response.text())
.then((text) => {
const blob = new Blob([text], { type: 'application/javascript; charset=utf-8' });
const objectUrl = URL.createObjectURL(blob);
return context.audioWorklet.addModule(objectUrl)
.finally(() => URL.revokeObjectURL(objectUrl));
})
Related
I have a .Net Core API and a React application using BabylonJs to render some 3D models. On my server side I am storing the 3D models that will be requested by the client to render into the scene. In order to do so I have allowed UseFileServer and UseStaticFiles on my .Net Core server. I have also created a Policy to apply for requests that require the CORS policy. The policy that I implemented is the following:
services.AddCors(options =>
{
options.AddPolicy("CorsPolicy", policyBuilder => policyBuilder
.AllowAnyHeader()
.SetIsOriginAllowedToAllowWildcardSubdomains()
.AllowAnyMethod()
.SetIsOriginAllowed((host) => true)
.AllowCredentials());
});
And I am applying it to the requests that target the Static files the following way:
app.UseFileServer(enableDirectoryBrowsing: true);
app.UseStaticFiles(fileOptions);
On the client side the request is being done by the Babylon library the following way:
SceneLoader.ImportMeshAsync(
"",
"http://localhost:9001/resources/objects/",
"sphere.glb",
scene
)
.then((result) => {
result.renderingGroupId = 1;
scene.createDefaultCamera(true, true, true);
scene.activeCamera.alpha += Math.PI;
})
.catch((error) => {
return null;
});
What happens is that I am receiving the following error only on google chrome and not on Firefox neither on Opera.
Also the responses to Firefox and Opera contain the missing header while the response to chrome does not.
Chrome:
Firefox:
Opera:
After some research time I found the solution for my problem. What was causing the issue was not CORS. It looks like Google has made a security upgrade to Chrome that has changed the Referrer-Policy to:
wgile both other browsers remain on:
As so, google only support CORS on https->https sites. After creating a self-signed certificate and open a port for https problem was resolved.
My company switched to B2C and now the login is performed with a redirection from another website. For this reason my login tests that used to work now are giving me a cross origin error.
Already tried adding chromeWebSecurity: false to cypress.json and it makes no difference.
Also tried to add this to index.js :
on('before:browser:launch', (browser = {}, launchOptions) => {
// `args` is an array of all the arguments that will
// be passed to browsers when it launches
console.log(launchOptions.args) // print all current args
if (browser.family === 'chromium' && browser.name !== 'electron') {
// auto open devtools
launchOptions.args.push('--auto-open-devtools-for-tabs')
// whatever you return here becomes the launchOptions
return launchOptions
}
if (browser.family === 'firefox') {
// auto open devtools
launchOptions.args.push('-devtools')
return launchOptions
}
})
Didnt make any difference either.
From what I read, many people are having this issue since 2018 and Cypress didnt seem to have solved it yet. Kind of make me nervous because I already have A LOT of tests written for cypress, so migrating would be harsh.
Do you guys know any workaround?
Here's the full error:
CypressError
Cypress detected a cross origin error happened on page load:
Blocked a frame with origin "my company's address" from accessing a cross-origin frame.
Before the page load, you were bound to the origin policy:
my company's address
A cross origin error happens when your application navigates to a new URL which does not match the origin policy above.
A new URL does not match the origin policy if the 'protocol', 'port' (if specified), and/or 'host' (unless of the same superdomain) are different.
Cypress does not allow you to navigate to a different origin URL within a single test.
You may need to restructure some of your test code to avoid this problem.
Alternatively you can also disable Chrome Web Security in Chromium-based browsers which will turn off this restriction by setting { chromeWebSecurity: false } in cypress.json.Learn more
Description/background
I had set up a script which opened a Google site of our company in Google Chrome (not headless) and did some automated work on that page. The login information had to be refreshed occasionally what for I manually logged in. That had been working perfectly the last couple of months until last week. Today I noticed that I get the above mentioned error message as a result of a server response with HTTP status 400 upon entering my Gmail address and clicking the Next button.
Steps to reproduce
Puppeteer version: 2.0.0
Platform / OS version: Windows 10
URLs (if applicable): https://sites.google.com/...
Node.js version: v12.13.0
What steps will reproduce the problem?
Run a Puppeteer script to open a Google Site which requires login.
(async () => {
try {
const browser = await puppeteer.launch({headless: false, userDataDir: "<ProfileDirectory>"});
const pageLogin = await browser.newPage();
await pageLogin.goto('https://sites.google.com/...', {waitUntil: 'networkidle2'});
...
await browser.close();
}
catch (error) {
console.log(error.stacktrace);
}
})();
Manually enter Gmail address and click Next.
Get error message "Sorry, something went wrong there. Try again." as a result of a server response with HTTP status code 400.
Update:
Manually opening Chrome (same userDataDir) and the respective Google site still works as usual.
Recommend to use playwright/puppeteer + Firefox. It seems like google adds something into chrome so they can detect the browser is automated or not
One of the comments on this post mentions that Google tries to block logins with Puppeteer, Selenium etc. this might be why you are getting a 400 error.
One of the recent comments on the aforementioned post, links a gist with some example code that might still work, haven't tried it though.
While I was doing research on Puppeteer for Firefox, I noticed that (1) Puppeteer downloads its own local Google Chrome binaries it is executing and (2) my installed Puppeteer version 2.0.0 was outdated. Meaning, the browser actually used by Puppeteer was probably also outdated. The solution was as easy as to update Puppeteer to the latest version 2.1.1.
I am facing an issue related to loading JSON data.
When I monitor JSON call on Developer Tools of Chrome, I get the following message in the network tab of Chrome Developer Tools.
Caution: request is not finished yet
Attaching a snip for reference:
It is caused by two-step response loading. If you are using some low-level API, make sure that you fetch not only headers, which arrive first, but also body content that comes later as a stream.
I had the same issue when using the fetch function in JavaScript. To solve it, make sure you call a method that reads the body of the response like json() or text():
// Sends request and loads only headers
fetch('/foo');
// Sends request, loads headers and then fetches the body as JSON
fetch('/foo').then(response => response.json());
In my case response headers were also loaded properly and I had a successful HTTP status code, but I was missing the body content and I had Caution: request is not finished yet inside Chrome Developer Tools.
consider removing all extensions and closing all the browser tabs
for me it helped - upon restart, all is well.
So strange
In my case, I needed to use response.text() instead of just using response. The usage of just response yields in "Caution: request is not finished yet"
fetch("API_URL_GOES_HERE", requestOptions)
.then(response => response.text())
.then(result => console.log(result))
A tip here would be: Open Postman's Code snippet and view the actual JS Fetch that is happening.
I ran into this issue due to a programming error that caused an infinite loop in my JavaScript code.
Some time ago Chrome would point out that a script is stuck, but for some reason such a message did not show up in my Chrome. Instead, I found this error in the network tab.
Trying Firefox, it showed the error message "This page is slowing down Firefox. To speed up your browser, stop this page".
This helped me figure out that in my case the issue was not related to the request, but was actually caused by a script running forever.
Apparently, the infinite loop in JavaScript causes Chrome to not finalize the request or at least it does not update this display. I am not sure why Chrome would not show a more meaningful error message that a script is stuck.
Is possible to intercept 404 error without using web server (browsing html file in the filesystem) ?
I tried with some javascript, using an hidden iframe that preload the destination page and check for the result and then trigger a custom error or redirect to the correct page.
This work fine but is not good on perfomance.
A 404 error is an HTTP status response. So unless you are trying to retrieve this file using an HTTP request/response, you can't have a genuine 404 error. You can only mimic one in something like the way you suggest. Any "standard" way of handling a 404 error is dependent on your flavour of web server anyway...
404 is a HTTP response code, and as such only delivered through the HTTP protocol by servers that speak it. The file:// extension isn't a real protocol response as such, it's a hack built into clients (like browsers) that enable local file support, however it's up to browsers / clients themselves whether they expose any response codes from their file:// implementation. In theory they could report them in the DOM, for example, but they would be response codes exposed to themselves, and as such rarely implemented. Most don't, and there isn't a standard way for it. You may look into browser extensions, like Firefox, and see if they support it, but then, this is highly unstandard and will likely break if you pop it on the web.
Why don't you want to use the server?
I don't believe that it's possible to handle a 404 error client-side, because a 404 error is server-side.
Whenever you load a webpage, you make a request to the server. Thus, when you ask for a file that's not there, it's the server that handles the error. Regular HTML/CSS/JavaScript only come into the picture when the server sends back a response to tell you that it can't find the file.
Steve
Because I was looking for this today. You can now do this without a server by using a Service Worker to cache the custom 404 page, and then serve it when a fetch request status is 404. Following the instructions on the google cache lab, the worker files looks as follows:
const filesToCache = [
'/',
'404.html'
];
const staticCacheName = 'pages-cache-v1';
self.addEventListener('install', event => {
console.log('Attempting to install service worker and cache static assets');
event.waitUntil(
caches.open(staticCacheName).then(cache => {
return cache.addAll(filesToCache);
});
);
});
self.addEventListener('fetch', event => {
console.log('Fetch event for ', event.request.url);
event.respondWith(
caches.match(event.request).then(response => {
if (response) {
console.log('Found ', event.request.url, ' in cache');
return response;
}
console.log('Network request for ', event.request.url);
return fetch(event.request).then(response => {
console.log('response.status:', response.status);
// fetch request returned 404, serve custom 404 page
if (response.status === 404) {
return caches.match('404.html');
}
});
});
);
});