Using The Debugger
Last updated
Was this helpful?
Last updated
Was this helpful?
When your application doesn't have the expected behavior in Run-mode, the best way to analyze and fix the issue is to get into each workflow action one-by-one to see where the wrong data is being computed, or where a condition is evaluated in a surprising way. That is what the debugger is for.
You activate the debugger by adding debug_mode=true at the end of the URL of the application in run-mode as a querystring. If you don't have another parameter in the URL, it will look like https://app.bubbleapps.io/index?debug_mode=true while if you do, it would be look like https://app.bubbleapps.io/index?param=value&debug_mode=true. When you access an app from the editor by clicking PREVIEW, the debugger will be automatically activated.
In order to protect your app and your work, the debugger is only accessible when you can edit the application in Edit-mode. If you don't have access to the app in the editor, adding debug_mode=true will have no effect. Note that, currently, Bubble does not offer the debugger on touch devices. You should use a desktop or a laptop to access the Debugger.
When the Debugger is activated, you'll see it at the bottom of the page, with sections for the Workflow Debugger and the Element Inspector. Note that as the Debugger can extend, Bubble automatically adds some space at the bottom of the page. This is only in debugging mode, and will not be visible when your app is used in production.
The left side of the Debugger is the Workflow Debugger. You can see three buttons that control how the debugger behaves when a workflow is being triggered. Three modes are possible:
The 'normal' mode runs workflows without interruption.
In 'slow' mode, there is a one-second pause between each action and the next.
The 'step-by-step' mode lets you control the execution of the workflow. This is the mode you'll use the most often.
When you're running a workflow in slow/step-by-step mode, you'll see a representation of the workflow and the evaluation of the fields for each action. Anything in blue in the property list is dynamic (defined by an expression in the editor), and clicking on it will let you understand why it's evaluated this way.
When more than one workflow is being executed, each of them will run one after another, and all will follow the same execution mode in the debugger. This also applies to custom workflows, the debugger will get inside the custom workflow, and will resume the outer workflow when finished. The debugger status is saved when you refresh the page. If a workflow changes the page, or triggers a page refresh, the resuming workflow will run the subsequent actions in the same mode.
If at some point you need to expedite the execution of the workflows, you can click on 'normal', which will run the remaining actions in normal speed.
When you are working on complex pages, with many workflows, the step-by-step mode may not be ideal, as it will stop too often. If there is a specific workflow, event or action that you want to investigate, you can add a breakpoint that will turn the debugger on in step-by-step mode when this event or action is run. You set this setting in the Application Editor, and this will get saved in your application. Note that this setting will only have some effect when the debugger is on (meaning you have debug_mode=true in the URL), and will not impact how your application is executed for your users.
You sometimes need to figure out why an element is displayed in a particular way, especially if you're using conditions or displaying some data. The debugger lets you pick an element on the page and see the list of conditions and fields and their values in the current situation.
Click on 'Inspect' to turn the Element Inspector on. When the Inspector is on, the debugger will be expanded and you'll be able to pick the element you want to inspect. You pick an element to inspect either by clicking on it (it will not trigger a workflow then), or by finding in the dropdown menu. This is especially useful to inspect an element that is visible (or understand why the element isn't visible). You can search an element by name by typing in the input.
Once an element is selected, you'll see on the right the different properties and conditions, and how they are evaluated. You will also be able to see at the bottom of the inspector section the list of custom states and other values elements have in their context (such as a group's content). Here is what the list of apps in the Showcase looks like in the debugger. You can see the different fields and the values. When a value is blue, it's a dynamic expression, and clicking on it lets you evaluate it piece-by-piece.
If you are using conditions, the debugger will show you in green the conditions that are evaluated to yes, and in red those that aren't. Here again, clicking on the expression will let you evaluate piece-by-piece.
The debugger can help you understand how a dynamic expression is evaluated in Run-mode. The evaluator on the right side of the debugger lets you click on each item of an expression and will display below the value. It can display the result of a database search, results from an API call, etc.
If an expression is using another expression as a parameter, you can get inside each expression one by one and analyze where the data is coming from. If you are referring to some elements in an expression, hovering the element in the expression evaluator will highlight the element on the page.
The debugger is also useful to debug privacy issues. Privacy rules can lead to complex situations to debug, as it can hide some fields for a thing. When you click in the evaluator on a thing that has been censored, a red mention will be shown. The way it works is that it compares the value that is visible to the current app user, and the raw thing, when no privacy rule is applied. If the two objects are different, a privacy rule is applied, and a mention will be visible.
The debugger is also where you can see run-mode execution errors. For instance, if you're making an API call to a service, and that service returns an error because a parameter is missing, that's where the error will be shown. When an error is happening in a workflow or in an element, the icon will turn red, and will become clickable. Clicking on it will reveal the list of errors.
When you hit an issue, especially if you are using external services via plugins, one of the first things you should do is check if you are hitting an execution error.
This is how a workflow that creates a thing (a to-do list item) and resets the input would look in slow mode. This example is taken from the demo app .
