I'm using an API on my website to send emails to the users and while testing my call I noticed I was receiving the email twice.
So the url looks like "localhost/api/sendEmail" and, at least on Chrome, when I'm on localhost and I start typing "/ap" the url is automatically completed.
And I can see on Fiddler that Chrome (well I think that's him) is actually calling it before I press Enter so the mail is sent, and when I press Enter it is of course sent a second time.
This is not a problem since it won't be directly callable by the end-user, but I was just wondering what is the purpose of this first call ? Is Chrome pre-calling the page to make it faster to load ? Can it cause problems in different situations? Can one prevent Chrome from behaving like this?
Again, not a problem at all, but I'm just wondering.
This is Google's prefetch feature, which loads the page quicker, assuming you execute the auto-completed URL.
You can disable this option in Google Chrome:
Settings > Advanced Settings > Privacy: (uncheck) Prefetch resources..
Update 2019
I came across a similar question on superuser, which I provided an updated answer for.
Disable page load prediction service
chrome://settings/ -> expand Advanced section
Disable NoState Prefetch
chrome://flags -> search for "nostate"
Related
When using WhatsApp web, when you send a message there are no requests showing up, but the message still delivers. Why are there literally no signs of any requests made in the networking tab??
And how to make it visible (if it's hidden)??
Note: It happens only on WhatsApp web. On other sites, it works and shows the GET and POST requests...
This is a common source of conufsion when debugging networking requests done from the web.
Normally, developers look at these network requests from top down and assume that the lowest one is the most recent request made - therefore assuming that the request must be at the bottom. For 'plain' HTTP this is correct. However, many apps that want to show data in real-time, use WebSockets to communicate with an API.
The same thing happens in the Web-version of Whatsapp. Only assets like the actual JavaScript-app, icons etc are loaded using plain HTTP. Then, a WebSocket is opened through which messages are exchanged for example.
To see the actual request do the following:
Open DevTools, go to networking tab
Open Whatsapp web. Make sure that at this step (1) is already recording!
Filter for "WS" in the filtering bar
There will be only very few results which you can click to investigate
Inspect this Socket using the 'messages' tab
Now send a message, you will see a message called binary message with your message as payload.
Try "Settings" -> "Preferences" -> "Network" -> "Record network log" in Chrome DevTools. This checkbox is probably unchecked in your situation. So, check it.
Otherwise if "Record network log" is checked, then try "Settings" -> "Preferences" -> "Restore defaults and reload".
I am trying to build a PWA. I managed to trigger the prompt a first time and installed the app on my shell (desktop). I then deleted it and I would like to force the prompt to reappear (for debug purpose) but it won't.
I set my chome flag Bypass user engagement checks to enabled, but there's still nothing I can do to trigger the prompt.
When I click on the console setting Application>Manifest>Add to homescreen, nothing happens and I don't receive any error message either.
It's exactly the same code that worked the first time. I just want to trigger it again now that the desktop shortcut has been deleted.
Also struggled with this issue.
At last found that going to chrome://apps/ and removing the app will enable to re-add it
If the chrome://flags/#bypass-app-banner-engagement-checks flag is enabled and you are still not getting the banner, its high likely one of PWA criteria is not met anymore.
It might have worked before. But with the changing code, something might have went wrong with Service worker, accessing via HTTP instead of HTTPS or having an invalid certificate kind if issues might have made your app not eligible for App install banner.
Validate: Validate your current sites PWA eligibility using Chrome Developer tools -> Audits -> Perform Audit -> Progressive Web App. See if all goes through regarding PWA criteria and if you see all looks good and still you don't get the Install Banner, post the Audit screenshot to give us some idea on whats going on.
You can just also just set it in the Developer Tools under Application by checking on Update on reload or click on Unregister to completely remove the SW. Dirty, but does the trick all the time.
I am trying out Google Colab, but then I keep getting this pop up box that says:
Error
Could not access the resources needed to display output.
This is probably because third-party cookies are not allowed by your
browser.
NotSupportedError: Failed to register a ServiceWorker: The user
denied permission to use Service Worker.
While turn off Block third party cookies worked for me from here, I would like to keep the setting to be turned on at all times for the sake of our privacy.
Currently I will have to have another tab next to the Colab tab the so that after I have finished using Colab, I can turn it off right away and not to forget it. BUT I would have to do it every time I use Colab.
To solve this, I have tried to follow the chrome help guide and added https://colab.research.google.com and [*.]google.com to the Allow whitelist on Cookies. However the error pop up would still show. I also tried https://colab.research.google.com[/*], but chrome said its not a vaild domain.
Is there a way to allow Colab domain cookies for that?
The output cell is an <iframe> element. It has a url like
https://jbe1910iol-colab.googleusercontent.com/v2/usercontent/8b5e8f2bbe60490e/outputframe.html
So, you can try adding [*.]googleusercontent.com to the whitelist as well.
Not sure if it will work though. Hope it does.
For Google Chrome, go to the cookies settings page
Type this in the address bar
chrome://settings/content/cookies
In Allow section, click add button.
paste this [*.]googleusercontent.com
That's all.
As Korakot Chaovavanich's explanation, I added steps
I would like to view HTTP POST data that was sent in Chrome.
The data is in memory now, and I have the ability to resubmit the form.
I know that if I resubmit the server will throw an error. Is there anyway I can view the data that is in Chrome's memory?
Go to Chrome Developer Tools (Chrome Menu -> More Tools -> Developer Tools)
Choose "Network" tab
Refresh the page you're on
You'll get list of http queries that happened, while the network console was on. Select one of them in the left
Choose "Headers" tab
Voila!
You can filter for HTTP POST requests with the Chrome DevTools. Just do the following:
Open Chrome DevTools (Cmd+Opt+I on Mac, Ctrl+Shift+I or F12 on
Windows) and click on the "Network" tab
Click on the "Filter" icon
Enter your filter method: method:POST
Select the request you want to debug
View the details of the request you want to debug
Screenshot
Tested with Chrome Version 53.
You can use Canary version of Chrome to see request payload of POST requests.
Another option that may be useful is a dedicated HTTP debugging tool. There's a few available, I'd suggest HTTP Toolkit: an open-source project I've been working on (yeah, I might be biased) to solve this same problem for myself.
The main difference is usability & power. The Chrome dev tools are good for simple things, and I'd recommend starting there, but if you're struggling to understand the information there, and you need either more explanation or more power then proper focused tools can be useful!
For this case, it'll show you the full POST body you're looking for, with a friendly editor and highlighting (all powered by VS Code) so you can dig around. It'll give you the request & response headers of course, but with extra info like docs from MDN (the Mozilla Developer Network) for every standard header and status code you can see.
A picture is worth a thousand StackOverflow answers:
On Chrome 96 DevTools Network Tab;
After clicking the request, there is a "Payload" tab that shows the Form Data:
You can view the data as url encoded / decoded:
You can view the data as source / parsed:
Even if the method is GET you can see the Payload as Query String Parameters:
It has a tricky situation: If you submit a post form, then Chrome will open a new tab to send the request. It's right until now, but if it triggers an event to download file(s), this tab will close immediately so that you cannot capture this request in the Dev Tool.
Solution:
Before submitting the post form, you need to cut off your network, which makes the request cannot send successfully so that the tab will not be closed. And then you can capture the request message in the Chrome Devtool(Refreshing the new tab if necessary)
The Network tab is all you need...
The other people made very nice answers, but I would like to complete their work with an extra development tool. It is called Live HTTP Headers and you can install it into your Firefox, and in Chrome we have the same plug in like this.
Working with it is queit easy.
Using your Firefox, navigate to the website which you want to get your post request to it.
In your Firefox menu Tools->Live Http Headers
A new window pop ups for you, and all the http method details would be saved in this window for you. You don't need to do anything in this step.
In the website, do an activity(log in, submit a form, etc.)
Look at your plug in window. It is all recorded.
Just remember you need to check the Capture.
I spent the day debugging my website, because I seem to be getting randomly logged out, but just on Chrome on Android.
After reviewing the server logs, I see requests from my Android tablets IP hitting my server for links that I never clicked on. After some experimentation I see every couple of links I click, Chrome will fetch another link at random in the page that was not clicked.
The issue is that there is an a link in the page with an href="logout" which will sign in, and Chrome calls this all on its own, disconnecting the session. I suppose if I changed the link to call a POST operation Google would not fetch it, but I can't see why Google would be fetching links that were not clicked.
This is very odd, and does not occur on Firefox, or Chrome on Windows.
Not sure if this is some sort of virus on the tablet, or some thing Google is doing to check the content of pages that it would not have access to without the session.
I have seen Google do this before, but only when there were Google ads in the page, then Google would fetch the links twice so that it could get the page content to choose the ad. This seems a huge privacy issue, as Chrome is fetching private data from the session.
So the issue is that Chrome is using a new feature "prefetching".
This is a "feature" that will have Chrome randomly fetch any linked URL from the page.
This seems like a very error prone "feature" for Chrome to enable by default. Seems like it could give the user cached or stale data, or change the server's state causing obscure difficult to debug issues. This will also use double the amount of the user's data (and server's CPU), which you would think would not be desirable to most users that pay for their data.
I confirmed this by disabling the feature in Chrome.
My solution was to switch the logout call to use a POST through a element.
See, https://www.technipages.com/google-chrome-prefetch