I have a problem with the Google App Script debugger.
When I run my script in debug mode, it is correctly stopped at breakpoint on the first loop of my 'for loop'. But when I click the Play button (of the debugger) to continue to the next loop, the variables are not changed in the debugger window (the window that shows the variables values), as if the debugger remained blocked on the breakpoint. But actually, as the work done by my script on the next loops is done, I can see that the script actually didn't remain blocked on the breakpoint.
So, the debugger gives the feeling to be blocked on breakpoint (without possibility to continue the script on the next loops) even if it is not the case.
Anybody had this issue ? How to solve it ?
This appears to be a bug!
There are a couple of reports on Google's Issue Tracker which detail the same kind of behaviour:
Problem during Debug: Variable doesn't grow linearly but skip some values
Array Error
Google does seem to know about this issue but if it's causing problems you can file your own bug about it here.
You can also hit the ☆ next to the issue number in the top left on the aforementioned pages which lets Google know more people are encountering this and so it is more likely to be seen to faster.
Related
I was making small edits to the startup script of my Compute VM in the Console, without issue. Now all of a sudden I get this "Make sure all fields are correct to continue" banner that appears when I try to save. Even if I click edit, make NO changes, and try to save, the same banner appears. For some reason I can no longer make changes to this VM. This is a VM that has been running daily without issue for over a year, with periodic edits to the startup script.
The message gives absolutely no specifics about which fields are the problem. And I don't think I actually changed any fields other than the startup script.
I searched online for this problem but have only found one similar issue but not for Compute. See https://www.googlecloudcommunity.com/gc/Workspace-Q-A/Getting-quot-Make-sure-all-fields-are-correct-to-continue-quot/m-p/404955.
See attached screen shot.
Any ideas?
I have a JS script I have been trying to debug. It works fine. It has alerts, prompts, and console.log messages. I noticed in Firefox the console.log messages get printed to console "live" as they occur in the script, yet in Chrome, one has to wait until the script has completed before the console.log messages get shown. This behavior made me think it was a bug or that I had simply clicked the wrong filter or option.
I'm still not sure why Chrome behaves the way it does.
Any insights? I would prefer to see messages occur as they are happening
Ok. After hours of fiddling about, I figured out the culprit. Chrome can indeed show console messages as they are occurring. Apparently, the "Pause on caught exceptions" option was turned on by accident and had stopped the log from showing up.
If anybody else has this problem ... you will need to wait until the script finishes and click on one of the messages. In my case, it was "bs.js". From there you will see an option "Pause on caught exceptions" where you can toggle the option. Hope this helps someone.
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.
In NodeJS, you can run a script with the --debug-brk option, which pauses your script at the first line. You can then attach with a debugger and resume, ensuring you can hit any breakpoint no matter how early it is in your script.
Is there something similar in Chrome / Chrome Debugging Protocol?
I use an external debugger to debug JS in Chrome. Chrome is launched via command-line, with remote debugging enabled, pointing to a local server with my website / app. Once Chrome is launched, the debugger attaches to the page, but that takes time - by the time the debugger is attached, the scripts have pretty much already executed, meaning I cannot hit breakpoints that are early in the website / app's life cycle.
I thought of adding debugger; statements at the beginning of every script, but that would be annoying over time. I also think that the Chrome dev tools need to be open for debugger; statements to actually pause, so that might not even work.
In Chrome DevTools, you can use 'Event Listener Breakpoints' to force the execution to pause on 'Script First Statement'. There are others, such as load, which happens a little later on. You can then resume execution until the relevant breakpoints should be hit.
I have written a Google Apps Script UiApp application with close to 1000 lines of code and a fair amount of handlers and callbacks. The app was working fine, but as the code grew the app suddenly got a lot of "unexpected error occurred" messages. The error messages occur as the app is loading and are intermittent. I can try the app one minute and get the error. Then refresh and the error goes away. Refresh again and the error may very well appear again. They occur in both the test and production url.
Because the error is random I can't trace it to any particular line of code, Are there processing limits that might cause this? Does Google Apps have limits on lines, widgets or handlers? If so, could those be causing these errors and are there ways to get the limits increased? Is there anything I can do to trace this problem?
Frequently, the "unexpected error occurred" message is attributed to your handlers trying to work with elements that have not yet been created and added to your app. For example, if you try to run a handler on a panel that may very well exist in your code in a function some where, you will get an unexpected error if the panel has not yet been created.
Follow the flow of operations and functions in your code to see if something is trying to execute on an element that may exist in a function somewhere, but hasn't been added to your app yet.
Additionally, if you are trying to handle elements that have Id's through ".forTargets(app.getElementById('myElement'))", check the names of your Id's very closely. If the name is wrong, you will get that error as well.
Bug squashing can be a time consuming, hair-pulling experience! When your code starts becoming spaghetti code, these errors tend to crop up. You may have to go back and re-design and re-write to clean things up.
Yes, the engine for Google Apps Script has all kind of limitations in terms of the number of callbacks you can make, the amount of time that can be spent on executing your script, etc. Our experience is that you should keep your code as small as possible and modularize things that might take a long time. If you're using your code in combination with a spreadsheet, use the spreadsheet as a container for storing the result of intermediate steps, and break your code into multiple scripts that will call each other once they're done. It will make your code more complex, but it will work a lot more reliably. And if your code is doing things which Google Apps Script was never designed for, move the code outside, to Google App Engine or another container (especially if you need server-side JavaScript).