I'm working on the Gmail addon with alternative runtime using nodejs. There is an option openDynamicLinkAction and the documentation says
https://developers.google.com/workspace/add-ons/reference/rpc/google.apps.card.v1
"An add-on triggers this action when the action needs to open a link. This differs from the openLink above in that this needs to talk to server to get the link. Thus some preparation work is required for web client to do before the open link action response comes back."
And nowhere mentions how the response structure should be to execute open link as a popup using openDynamicLinkAction.
Please help me with the proper usage of this option.
My copy of Google Chrome, on my laptop, fails to register all service workers. If I load any website that has offline functionality, devtools console outputs:
Uncaught (in promise) TypeError: Failed to register a ServiceWorker for scope ('https://googlechrome.github.io/samples/service-worker/basic/') with script ('https://googlechrome.github.io/samples/service-worker/basic/service-worker.js'): An unknown error occurred when fetching the script.
Note that the above error is from https://googlechrome.github.io/samples/service-worker/basic/, which is a technology demonstration made by google, specifically about service workers, specifically for chrome, not something I created. One other interesting thing is that service workers fetched from localhost can be registered with no problem. This would suggest an SSL issue (I think), but then again the host of the above website is github pages (is there any way my browser could be not trusting github pages? I haven't found any evidence to support that).
I get the same error if I directly type navigator.serviceWorker.register("https://googlechrome.github.io/samples/service-worker/basic/service-worker.js"); into the console on the same site.
It's not just a console message: if I load the website, then disconnect from the internet, then refresh the page, the browser reports "no internet" and does not load the website. The same thing happens if I use devtools>Application>Service Workers offline mode. This indicates that the service worker is failing to register. However, the Service Workers devtools tab does show service workers present – it just lists them as "redundant" instead of "active and running". Bizarrely, the "time received" is 1970-01-01.
I'm using Google Chrome Version 89.0.4389.114 (Official Build) (x86_64) on MacOS Big Sur. On other browsers (Safari, Firefox, and any browser on any other computer/mobile device), this error does not occur. I have restarted my Chrome multiple times since I first noticed the error, and updated it once since then. Neither fixed it.
I'm aware of a couple similar SO questions (here and here for example), but all of them have accepted answers about how the website creators can fix bugs in their site. This bug is appearing on websites I did not create, and seems specific to my browser (which I haven't tampered with in any way). The main reason this is driving me nuts is that I really really like Chrome's devtools, and I would like to use them for a current PWA project.
If anyone familiar with Chrome's inner workings knows what could be causing this, or if anyone has solved this in the past, I will be forever in your debt.
When I try to publish a google script, it keeps loading with a message that says "getting data" or something like that but in spanish.
And it never ends, it keeps saying that.
I have trying cleaning the cache and cookies, also try with private browsing
It never ends loading, then it won't let me publish it.
How can I publish the script?
This is an image of the message that appears in spanish
It says Deploy as a web app and below, getting data.
If it is not a temporary server problem, it should be an error message not displayed. When the modal appears try to open the network tab of browser inspector and open the underlying sharingService request. The JSON response could contain a message like this or a little different:
Web apps can be enabled or disabled only by the script owner
I'm getting the following error when I try to publish:
This hosted web app has one or more app urls not owned by the developer.
The web_url of this hosted web app is not owned by the developer.
I am getting the green warning box as described in:
https://code.google.com/p/google-apps-script-issues/issues/detail?id=1520
However, I'm hitting the refresh button and no joy in the solving the problem. I've published a lot of apps scripts in the past and never had this issue.
You have to register your url with the Google webmaster tools program and they will give you code to fix this. In case you have already done that, just go and verify again. It happened to me as well and I had to verify the site again. It works!
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.