Dynamic values return undefined/none on Safari but work on Chrome

Ask us anything
1

I’m building a chat widget where users can customize the bubble color. The color is stored in Supabase and needs to be applied dynamically. This works perfectly on Chrome but fails completely on Safari.

The original problem:

In a WeWeb binding/formula, I access the color like this:

context.component?.props?.['24cfb775-fba6-47f4-82fc-0a74f7c3da74']?.styles?.backgroundColor

  • Chrome returns: #18181B (correct value)

  • Safari returns: none

What I’ve tried:

1. Breaking down the optional chaining:

const props = context.component?.props;
const componentProps = props ? props['24cfb775-fba6-47f4-82fc-0a74f7c3da74'] : null;
const styles = componentProps?.styles;
const backgroundColor = styles?.backgroundColor;
return backgroundColor;

Result: still doesn’t work on Safari.

2. Using CSS custom properties as a workaround:

Set a default in CSS:

:root {
  --chat-bubble-color: pink;
}

Then override it via JavaScript workflow:

const color = formulas['3af6a859-f267-46b7-a8ef-aa557f4b86bc']()?.styles?.backgroundColor;
if (color) {
  document.documentElement.style.setProperty('--chat-bubble-color', color);
}

  • Chrome: works, CSS variable gets updated to the database value

  • Safari: formula() returns undefined, CSS variable stays on default

3. Debugging the formula step by step:

const formula = formulas['3af6a859-f267-46b7-a8ef-aa557f4b86bc'];
const result = formula();
console.log('result:', result);

  • Chrome: logs the correct object with styles

  • Safari: logs undefined

4. Triggering on button click instead of page load: Same result — undefined on Safari even when manually triggered after page is fully loaded.

5. Removing all optional chaining syntax: Still undefined on Safari.

The core issue is that accessing dynamic data from Supabase via WeWeb’s context/formulas works on Chrome but returns undefined or none on Safari. This makes it impossible to apply any user-customized styling on Safari.

Is there a Safari-compatible way to access collection/variable values? Or is this a known bug with WeWeb’s formula system on Safari?

I also tried several AI-based workarounds, approaching the problem from different angles, but nothing produced a consistent or professional result. I’m hoping someone can shed some light on this :folded_hands::folded_hands::folded_hands:

1 Like
2

Hey Yann :waving_hand:,

Thanks a lot for taking the time to break down the issue so clearly and test different approaches, this level of detail is super helpful.
​
I’ll pass this to the team so we can investigate the Safari-specific behavior, but I don’t have an ETA for a concrete answer or fix yet.
​
As soon as there’s an update or a recommended workaround, I’ll come back to this thread and let you know.
​
Happy holidays :christmas_tree:

3

Hi, any informations about this please ?

Based on Cloudflare’s global report, 20% of traffic comes from Safari browsers. We really need to know how WeWeb handles this issue or if it’s even on the roadmap

Are there best practices we missed, or is it better to abandon “logical CSS” completely when it comes to Safari? Can we get a consistent answer or explanation please?

I’m insisting because of the number of tickets that have been waiting for the “team investigation answer” for years.

4

Hey @attlas !

Are you having this specific issue while on the editor or with your app live in production?

5

In the live app, in production. If any Weweb logic (formula) exists to set a background/text color, it doesn’t work with Safari. Even with direct Javascript

6

Hey @attlas, can you share your editor and production app url where we can see this happening?
You can send me a private message or talk with the support team

7

Hi Augustin, I was preparing the debug environment and setting up access for support, and I noticed that Safari is now serving CSS generated from WeWeb JS formulas :person_shrugging:

I don’t have any idea what happened, whether Safari released an update or WeWeb fixed something. But I’m pretty sure there was an issue there, considering the amount of time we spent trying to fix it.

If we encounter new issues related to this in February, I’ll document them there and share access directly with support

1 Like