Bugfix: Revert iframe z-index to -1 in resize listener #5448

[nick-vincent]

Problem:

As discussed in issue #5448:

When an element uses block-level bindings (e.g. bind:clientHeight), the resize listener appends an "invisible" <iframe> inside the element with a z-index of the element minus 1.

However, when the element has other children elements with z-index: auto, this results in the <iframe> being layered "above" the children. To illustrate:

resize-bound element: z-index: 100
|- child: z-index: auto
|- child: z-index: auto
|- iframe: z-index: 99 <-- layers above the children

Although the <iframe> has pointer-events: none, it still blocks scrolling on child elements in certain browsers, namely macOS Safari and iOS browsers:

Prior to this diff, the <iframe> was assigned z-index: -1, which effectively layers it below any children elements.

Screenshot:

Solution:

This change reverts back to setting the <iframe> to z-index: -1 which no longer obscures children of the bound element.

[nick-vincent]

I see that some CI tests were cancelled, possibly due to timeouts? Not sure how to rerun them.

[benmccann]

@nick-vincent I wouldn't worry about it if it's just a timeout. I re-triggered them and everything passed

I'm not very familiar with the svelte codebase, but is there anyway we can add a test for this? If this is an area where we've hit some edge cases it seems like a useful place to make sure those are covered

[nick-vincent]

@benmccann Thanks for kicking the builds for me. I've added a regression test for this fix.

Also, as a sanity check, I'd appreciate if @mrkishi or @Conduitry could weigh in on why this changed in the first place. I couldn't find any discussion about it in the relevant pull request.

[mrkishi]

This looks good!

I don't remember why I did that. I must have had a separate issue and blundered an incorrect fix, because z-index - 1 seems wrong indeed, regardless of it being an iframe or object. My apologies!

[nick-vincent]

Thanks for taking a look, @mrkishi! Didn't want to inadvertently introduce another regression.

[nick-vincent]

Looks like this PR is good to go... is there any other action I should take to get this merged?