In a calling app built with the Calling Extensions SDK (@hubspot/calling-extensions-sdk), we are displaying the app in both of the following contexts:
calling remote: The screen pinned to the HubSpot navigation bar (iframeLocation: 'remote')
calling window: A standalone calling window (iframeLocation: 'window')
When we switch the UI layout within the app to one with a different width on one of the screens, the synchronized UI on the other side also switches. However, the size of the display area on the other side does not match the updated UI, resulting in extra padding or content being cut off.
Steps to Reproduce
Open both the calling remote and calling window.
On one of the screens, switch the in-app UI from a narrow layout to a wide layout, or vice versa.
On the other screen, check the UI layout against the size of the display area.
Actual Behavior vs. Expected Behavior
The UI layout change is reflected on the other side as well, but the display area sizes do not match. We expect the app to be displayed at the width and height appropriate for the updated UI, without any extra padding or clipping.
Based on the observed behavior, we suspect that while the UI state synchronization is working, the size update of the HubSpot calling iframe or its container may not be keeping up. However, the root cause has not yet been identified.
Questions
Does resizeWidget({ width, height }) behave differently between calling remote and calling window? Are there additional constraints?
Is there any specific process required to update the size of each screen, or are there any known issues similar to this?
We have reproduced this issue with multiple internal users and in different browsers. We would appreciate it if you could share any verification methods or workarounds.
resizeWidget behavior is not documented as differing between remote and window, it’s described generically as “sends a message to notify HubSpot that the calling app needs to be resized” using height/width. There is currently no documented size caps or constraints for either context. (Here you can find more information: calling-sdk)
No separate resize-sync process is documented. resizeWidget only affects the iframe it’s called from, it is not something HubSpot automatically propagates to the other iframe. The docs only describe synchronizing UI/call state (via onReady’s iframeLocation plus the Broadcast Channel API), not resize messages. (Here is the documentation for this: receive-incoming-calls#calling-state-synchronization)
So, it seems that your UI-state broadcast correctly tells both sides to switch layouts, but each side’s extensions.resizeWidget() call must be triggered independently in each iframe’s own code, if only one side calls resizeWidget (or if the broadcast handler updates the rendered layout without also calling resizeWidget on that same iframe), the UI will change but the container size won’t match. As a workaround, can you please ensure your broadcast message handler explicitly calls extensions.resizeWidget({width, height}) in both the remote and window contexts whenever a layout switch is received, not just in the iframe where the user initiated the switch.
Let us know how it goes!
Thanks,
Bérangère
This post was created with the assistance of AI tools
Thank you for the clarification. We reviewed our implementation and found that resizeWidget() is called in the iframe where the user initiates the layout change. The layout preference is synchronized to the other iframe via localStorage, but the receiving iframe updates its UI without independently calling resizeWidget().
Based on this code review, our implementation appears to match the scenario you described. We have not yet tested whether calling resizeWidget() independently from both iframes resolves the issue.
Since this previously worked without changes to the relevant code on our side, could you also confirm whether there have been any recent changes to HubSpot’s resize handling?
We confirmed that calling resizeWidget() independently from both iframes resolves the sizing issue in our testing.
However, our existing implementation previously worked correctly without this additional handling, and the issue began occurring without changes to the relevant code on our side.
Could you please check with the responsible engineering team whether HubSpot’s resize handling has changed, and clarify why the previous implementation stopped working? If this was an intentional behavior change, please share when it was introduced and any relevant documentation or release notes. Otherwise, could the team investigate whether this is a regression?
Although the workaround resolves the immediate issue in our testing, we would like to keep this inquiry open until the change in behavior has been explained.
Hi @Kuwahara and thanks for the follow-up! I’m glad to hear the workaround resolved the issue.
I checked with our engineering team and can confirm that this behavior is expected. The resizeWidget({ width, height }) function only resizes the iframe where it’s called.
While the calling remote and calling window synchronize call states (such as incoming calls or call endings), resize events aren’t shared between them. This means each iframe needs to call resizeWidget() independently when its layout changes, just as you’ve implemented.
Regarding your question about recent changes, our team reviewed the resize handling and couldn’t identify any recent changes to this behavior. Both contexts have always required independent resize calls, so we don’t currently believe this is a regression.
To clarify your original questions:
resizeWidget() works the same way in both contexts, with no documented context-specific restrictions.
No additional steps are needed. Just ensure that when your synchronization handler updates the layout, it also calls resizeWidget() in the corresponding iframe.
Since you mentioned this worked differently before, could you share approximately when you first noticed the change and which SDK version you’re using? This would help us investigate further.
We’ll keep this thread open, and please let us know if anything else comes up!
Thanks again for working through this with us!
Bérangère, HubSpot Community Manager
- For information, I’ll be out of the office from the 26th to the 30th of October included -
Hi @Kuwahara, thanks for your patience while we looked into this with our internal team.
We heard back from the team that owns the Calling Extensions SDK. They reviewed the resize handling and don’t see any recent change on HubSpot’s side. Integrators have always needed to call resizeWidget() in each iframe to resize it, and that applies to both the calling remote and the calling window. So at this point we don’t believe this is a regression.
Since you’ve confirmed that calling resizeWidget() from both iframes resolves the sizing issue, that’s the approach we’d recommend going forward. If you notice anything else that looks off, or you find a reproducible case where the sizing breaks even with independent calls, please share the details here and we’ll take another look.
Thank you for checking with the engineering team and for the clear explanation.
We understand that resizeWidget() only affects the iframe that calls it, and that each iframe (calling remote and calling window) needs to call it independently. We have implemented this and confirmed that it resolves the sizing issue.
We have no further questions, so this topic can be closed on our side.