The debugger
When encountering unexpected behavior, the debugger comes in handy for closely examining each step of a workflow or the details of an element as the app is being used.
The debugger primarily serves two key purposes:
Run workflows action-by-action and check data (such as the result of a search) related to each step
Inspect the elements on the page to check their attributes, conditions and associated data
The debugger does not have any visible parts in the Bubble editor, but is visible when you run your app in Development.
Enabling and disabling the debugger
When you click Preview to see your app in run-mode, the debugger is automatically activated. If you want to enable or disable it, you simply have to change the debug_mode. When the debugger is enabled, you will see the parameter in the URL:
A full URL will look like the following:
...or if you have multiple URL parameters:
The debugger is only accessible in the and adding the URL in Live will have no effect. It is meant for desktop use and is not designed to work on mobile.
To disable the debugger, simply remove the parameter, or set its value to false.
Using the debugger
When the debugger is active, you will see a bar at the bottom of the screen when you preview your app:
When the debugger is enabled, Bubble automatically adds space at the bottom of the page. This is only visible in debugging mode and not to your Live users.
The left-hand side shows the different controllers for inspecting workflows
The right-hand side shows the controls for inspecting elements
Workflows
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:
Normal mode runs workflows without interruption.
Slow mode runs workflows with a a one-second pause between each action
Step-by-step' mode lets you control the execution of the workflow by pausing between each action until you click Run next (only visible when step-by-step mode is enabled)
Step-by-step is the most widely used debugger mode, as it gives you complete control over each action step, allowing you to progress at your own pace.
When the mode is active, Bubble will work for a workflow to be triggered by an event. As soon as that happens, it will pause on the event itself so that you can check what triggered it and any associated
Clicking Run next will move on to the the next step: the Create a new Product action:
Note the numbers in the screenshot above:
In this example, we inspect the Name field of the Product we are creating, where the value "T-shirt" is displayed. By clicking the value, we can trace the data source from which it is derived.
After clicking the value, we can see its data source on the right-hand side: in this example the value came from an input form called Input Product name.
By pausing at each step and examining the details of each action, you can verify if the data yields the anticipated values and is saved as intended.
The debugger status is saved when the page is refreshed. If a workflow navigates to a different page or triggers a page refresh, the resuming workflow will execute subsequent actions in the same mode.
Adding breakpoints
When working on complex pages with numerous workflows, the step-by-step mode might not be ideal since it stops too frequently. If you want to investigate a specific workflow, event, or action, you can add a breakpoint that activates the debugger in step-by-step mode when that event or action is executed.
Breakpoints are added in the workflow editor, either on an event or an action. As soon as Bubble encounters that event or action, it will pause and enable step-by-step mode from that point forward.
Note that this setting only has an effect when the debugger is active (meaning debug_mode=true appears in the URL) and will not influence how your application runs in Live.
Inspecting elements
Sometimes, you may need to determine why an element is displayed in a specific manner, particularly when using conditions or displaying data. The debugger lets you select an element on the page and view the list of conditions and fields, along with their values.
First, to enable Inspect mode, click the Inspect button in the bottom right corner. There are two ways to select an element to inspect:
You can click the element on the page (workflows will not trigger when you are in inspect mode)
You can use the dropdown list next to the Inspect button and search for/select the element from there (this is useful for elements that are invisible).
Understanding expression evaluations
When an element is selected, you can start to evaluate its properties, conditions and expressions. In the example below, we have selected the Create Product button.
Conditions are displayed in a separate list under the header Conditions. If they are in red color, it means the condition does not return true. If the condition is true, it will be displayed in a green color.
Digging into expressions
By clicking the relevant , you can take a closer look at each step and how it evaluates.
In the example above, we can check the last part of the expression: is logged in. We can see that this part of the expression returns a no.
If we click the first part of the expression, we can see the parameters associated with the data source Current user:
Any expression can be inspected in this way. Most fields on this user are empty since they are logged out, but you can see the unique ID and Created/Modified date that Bubble generates for all users who visit your app.
Each expression allows you to inspect every data source, operator and comparison. Any sub-expressions are also accessible by clicking them.
Run-mode execution errors
The debugger also lets you identify run-mode execution errors, such as when an API call to a service returns an error due to a missing parameter. When a workflow or element encounters an error, the debugger icon turns red and becomes clickable.
Clicking on it reveals the list of errors.
When you encounter an issue, particularly when using external services through plugins, checking for execution errors in the debugger should be one of your initial troubleshooting steps.
Other ways to learn
Last updated
