Breaking changes on clickability and date-times retrieved from page URL

Hi everyone,

We’re releasing a few bug fixes that we want to flag for you as they’re breaking changes.

Enforcing non-clickability for “This element isn’t clickable” property
Let’s say you have Element A, which has “This element isn’t clickable” checked and doesn’t have its own workflow. Element A is inside Element B, which does have a workflow and is clickable. In the past, you would be able to click on Element A, which would trigger the workflow on its parent element (Element B) as “This element isn’t clickable” wasn’t truly being enforced.

We’re now actually enforcing “This element isn’t clickable” on elements, so in the situation above, Element A would not be clickable, and no workflow would run.

If you do have child elements like Element A that were allowing clicks before and ran workflows on their parent elements, you can simply uncheck the “This element isn’t clickable” box on the child element to return to prior behavior.

Date-times from “Get data from page URL”
Previously, when using the action “Get data from page URL" to retrieve an ambiguous date-time that didn’t specify timezone (ex. 31 Dec 2014 23:59:59), the interpretation of the date-time was different on the client versus server. The server interpreted the date-time in UTC versus the client interpreting the date-time in the user’s current timezone.

Since other date-time inputs on Bubble interpret date-times using the user’s current timezone, we have made this behavior consistent on “Get data from page URL,” so it now will interpret these ambiguous date-times from the URL in the user’s current timezone. You can change this interpretation (to be interpreted in a different timezone) by adding/subtracting time to the entered date-time.


What if we have the following scenario?

Group A (clickable)
Holding Group B (clickable)
Holding group C (not clickable)

Does Group A inherit all the way down from group C?

So just to be clear, Group C is the parent of Group B, which is the parent of Group A? In that situation, Group A would not inherit non-clickability from Group C. You would need to mark the checkbox for “this element isn’t clickable” for Group A if you want it to be non-clickable.

Here’s how you can think of how this change impacts elements nested in groups:
A click on a child element travels outwards/upwards to parents, until either:

  • It hits something that isn’t clickable, and stops going
  • It hits something that has a “when this element is clicked” workflow, and runs the workflow
  • It runs out of elements to check
  • It hits a workflow

Therefore, if all the groups you mentioned have workflows that run when clicked, clicking on Group A will run Group A’s workflow; clicking on Group B will run Group B’s workflow; and clicking on Group C will not do anything (it is not clickable).

Let’s say you have another group (Group D) that is the parent of Group C (and everything within) and Group D is clickable and has a workflow that runs on click. Clicking on Groups A and B (and Group C which is non-clickable) will not run Group D’s workflow since Groups A and B are inside of a parent group (Group C) that is non-clickable. You can only run Group D’s workflow by clicking on Group D.

Hope this clears it up!

1 Like

Nice. I no longer have to create empty workflows for inner groups to keep the event from bubbling up the hierarchy. Plus, the mouse pointer now properly reflects the “clickability”. Double win.

1 Like

When using Icons (i.e., Googles Material Icons and Font Awesome Icons) in groups that have a Workflow, Icons no longer show a clickable pointer even though the Icon doesn’t have a Workflow. Text elements still function correctly.



This update broke my live app, how revert this update?, bubble it should implement this changes to update manually.

Im disappointing with this because cannt deploy a new version right now and cannt control the update


Button elements as well.

Oddly, Link elements configured as not clickable do display the clickable pointer and trigger the workflow up the hierarchy.

I’ve submitted a bug report.

Yeah, this change is actually causing more problems than fixing ones. Also, seeing strange behaviors with Drag and Drop elements and finding myself needing to use CSS on every icon and button that don’t have a Workflow :sweat_smile:. Hope they revert back or change it fast.

.no-click {pointer-events: none !important;}

1 Like

Every single time on this page just broke. It’s now adding 5 hours to my UTC time…

Not to mention that link now sends you to the wrong day… Huge issue tbh

Adding to the odd behaviour… clicking the previous day arrow now sends you back 2 days.

I have to agree. In fact, I thought it was Bubble’s policy for all breaking changes to be opt-in. It used to be that way, as mentioned in the following post from several years ago


Praying they revert on this update ASAP.


This update truly broke my site too! I have to figure what I have to do now! :sob:

1 Like

I just realized this has broken the functionality of my app too. Creating an appointment from one page to another drastically changes the arrival/departure time, which isn’t ideal in an appointment based app…

I’m going to have to send a lot of emails tomorrow.

Hello @grace.hong

But you guys did not implement this without asking the users right? I mean we will need to hit the upgrade button to get this going.


1 Like

Why would you tell people this after the fact. Why wouldn’t you let people know ahead of time…
It’s pretty disrespectful to be honest


Perhaps provide some instructions on how to fix it, when the change will become live…

1 Like

Yup experiencing the same here, what a bummer!

@grace.hong, @bubble… individual threads are coming in, too.

Smart money says these changes get reverted pretty quickly… definitely seems like they should have been opt-in.

Edit: Likely another one.

Edit: And another from someone who was already active in this thread, so you know it ain’t good.