fix(input-date-picker): calendar is displayed on open in Safari

[anveshmekala]

Related Issue: #13795

Summary

Fix calendar display in safari when input-date-picker is open in top-layer.

After analyzing layers in both Chrome(144) & Safari (26.2), date-picker wrapper container (.calendar-wrapper) is stacked behind an unkown node in Safari where as in Chrome it is promoted to the front. This workaround solution allows input-date-picker to have it own compositor-layer and promote it

There are other workaround solutions such as enabling top-layer-disabled or forcing repaint of input-date-picker as mentioned here https://codepen.io/jcfranco/pen/qENgLLZ?editors=1111. Disabling top-layer requires complex z-index handling from user & forcing repaint is not seamless in terms of UX.

Related articles: https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count

[driskull]

@anveshmekala I've noticed that safari has an issue with top layer and positioning using absolute. If you set the input-date-picker to use overlay-positioning="fixed" it seems to be fine in Safari.

From what I've seen the position:fixed forces a repaint whereas just using position:absolute does not. I ran into this in the maps SDK as well.

We likely need to open a Safari bug report and this seems to be a much simpler reproduction than what I was able to do in the Maps SDK.

Can we document the workaround and open a Safari bug report for this instead? The other option would be to force position:fixed when Safari is in use but I don't really like that either.

Would love to hear thoughts from others on the team. Especially @jcfranco

[driskull]

I'm not a fan 🪭 of browser sniffing 👃 🙅

[driskull]

Another potential solution would be to always position floating ui elements using position: fixed if the component does not have topLayerDisabled. This way, we could ensure that all top layer positioning is using fixed positioning. This is a bit too risky to do at this stage though. I really do think we have a Safari bug here as all other browsers don't have this issue.

[driskull]

I don't mind forcing a repaint using CSS if that solution works.

.force-repaint {
  transform: translateZ(0);
}

[driskull]

@geospatialem @DintaMel can we get a new issue to discuss a longer term strategy to make overlayPositioning only apply when topLayerDisabled is present? That way, we can always use fixed positioning when top layer is being used.

Using position of absolute shouldn't be necessary if the top layer is being used.

[DintaMel]

@geospatialem @DintaMel can we get a new issue to discuss a longer term strategy to make overlayPositioning only apply when topLayerDisabled is present? That way, we can always use fixed positioning when top layer is being used.

Using position of absolute shouldn't be necessary if the top layer is being used.

@driskull is this different than issue #13150? If it's the same, I'll add the context you provided above to it.

[anveshmekala]

Another potential solution would be to always position floating ui elements using position: fixed if the component does not have topLayerDisabled. This way, we could ensure that all top layer positioning is using fixed positioning. This is a bit too risky to do at this stage though. I really do think we have a Safari bug here as all other browsers don't have this issue.

Agree on the safari bug, this issue is persistent only with safari and surprisingly not reproducible in some machines ( Ex: Franco). Changing overlay-position did fix the issue but as you mentioned this could be risky atm which may cause regressions to exisiting setup irrespective of the browser.

Regarding below,

.force-repaint {
  transform: translateZ(0);
}

It works and it was used in earlier commits. will-change is a standardized alternative.

[driskull]

@driskull is this different than issue #13150? If it's the same, I'll add the context you provided above to it.

oh, yes we can use that issue and add more context 👍 Thanks!

[driskull]

@anveshmekala I'd rather not do anything safari specific here. Meaning no browser sniffing.

If we want to apply will-change for all browsers and it doesn't introduce any regressions, then I'm good with that.

Otherwise, we can advise users to use fixed positioning until the safari issue is fixed

[anveshmekala]

@anveshmekala I'd rather not do anything safari specific here. Meaning no browser sniffing.

If we want to apply will-change for all browsers and it doesn't introduce any regressions, then I'm good with that.

Otherwise, we can advise users to use fixed positioning until the safari issue is fixed

I think we can advise this workaround to the users and if they face any layout specific issues they could add this hack in their app perhaps while we continue to figure more robust solution.

[jcfranco]

@driskull @anveshmekala Great idea on using this to create a Safari bug repro case.

While browser sniffing should generally be avoided, it does have valid use cases. Here, it could help minimize performance impact on non-Safari browsers (see the warning and proper usage of this property can be a bit tricky sections of will-change), though I’m not sure if this is actually the case. A quick check with Chrome DevTools’ FPS meter should help confirm.

If there is a measurable perf impact, would it be possible to apply the workaround in the beforeOpen hook and remove it in the open hook? That might help minimize the impact window.

Since this is a workaround, it might also be simpler to apply an inline style directly on an internal element with proper workaround comments for context. Adding a reflected prop seems a bit unnecessary for something temporary, and keeping the logic closer should make removal easier later on.

[github-actions]

This PR has been automatically marked as stale because it has not had recent activity. Please close your PR if it is no longer relevant. Thank you for your contributions.

[jcfranco]

@anveshmekala I think we can close this out since there's a workaround and Safari recently landed a fix.