I am re-opening this because I think there is still a bug going on here. I have a brand new example page that is more realistic (does database access) and here is what is going on. This is a lot of info here, but it will help find the issue.
The page in question can be found here “live” https://helpexamples.bubbleapps.io/loadvisibility
and here for editing helpexamples | Bubble Editor
On the page called loadVisibility I have the following:
-
I have a group called ‘Items’ that contains a repeating group and two text elements in the RG. The data source for the repeating group is a table called testLoads which has records that have a name and an active bit. The source is a simple search for testLoads records. The RG and the text elements are set to be visible on page load. The group called "Items’ is set to NOT be visible on page load.
-
I have a group called ‘Refresh’ that contains a text element and a button. The text element and the button are set to be visible on page load. The group called "Refresh’ is set to NOT be visible on page load.
- I have a workflow on page load that sets a page custom state called ‘hasItems’ to “yes” ONLY when a SEARCH for testLoads where active=“yes” returns any records (count > 0). So if there are records in the table where active is set to “yes” than the custom state called ‘hasItems’ is set to “yes”
- I have conditional formatting on the group called “Refresh” that says if the custom state of the page, hasItems, is “no” AND the Page loaded (entire) is “yes” then make the element visible. So this SHOULD mean, wait until the page loads completely and then IF hasItems is “no” then show this group.

- I have conditional formatting on the group called “Items” that says if the custom state of the page, hasItems, is “yes” AND the Page loaded (entire) is “yes” then make the element visible. So this SHOULD mean, wait until the page loads completely and then IF hasItems is “yes” then show this group.

- Finally, I have a single record in the database that has the active bit set to “yes”.
So with all of this, and how I understand things to work, this is what should happen.
Both groups are set to NOT be visible on page load, so any elements contained in those groups should also not be visible. Therefore, when this page load, NEITHER group should be visible at first. On page load, the workflow should set the hasItems custom state to “yes” because there is a row in the database that has it’s active bit set. Once the page loads entirely, the conditional evaluations should happen and the Items Group should see that the hasItems state is “yes” and should become visible. The Refresh Group should see that the hasItems state is “yes” (and therefore not “no”) and should remain invisible.
What is happening instead is the Refresh Group is showing up for a quick second and then hiding itself.
Here is my presumption as to what is going on. I think the conditional validation is happening before the Page Load workflow is complete AND I think that it evaluates NO value to mean the same thing as “no”.
So from my perspective, something is not working as expected though what the right solution is, I am not sure.
BTW, I did a second test of this with a different custom state that was a ‘text’ type instead of a boolean (yes/no) and the same issue happened. You can see that here https://helpexamples.bubbleapps.io/loadvisibility2 and helpexamples | Bubble Editor
Any one of the following seem like solutions.
-
NULL value custom states should not evaluate to “no”/“false”.
-
Conditional formatting evaluation should not short circuit upon a null value. If the conditional says (only when value is “yes” ) then ANYTHING other than “yes” should not trigger the condition.
3.There should be a prioritization of page load workflows over conditional evaluation.
-
The should be a “pre load” workflow event.
-
Custom states should have default values that are loaded “server side”.
I am going to create a bug ticket for this because regardless of whether some of the proposed solutions seem like “features” what I am sure of is, if I told something to not be visible until X happens, it should respect that.
If anyone can point to any simple mistakes I made in validating this, let me know.
Otherwise, @emmanuel @josh Any insight on this?
Thanks in advance,
Marc

