Sticky Footer Windows 10 / Chrome 78

[ghost]

Been using Tingle for years... love the plugin. Using version 15.1. I noticed a bug on Windows 10 / Chrome 78 only and I was able to fix it with CSS. Just adding it here in case anyone else has a similar problem.

Notice how the sticky footer (where the arrow is pointed) doesn't stick to the bottom of a scrolling modal.

I fixed it by adding position: sticky to the CSS file

Not sure why. Adding position: sticky doesn't seem to have any adverse side-effects in other browsers. Tested in latest versions of IE, Firefox, and Chrome.

[robinparisi]

Hi @nbcnc,

I'm not sure if it's a Chrome 78 bug or a bad implementation with tingle but I would rather avoid using position: sticky because of to the current support: https://caniuse.com/#feat=css-sticky

[robinparisi]

After some tests, the bug seems to be related to backdrop-filter property. I can't go deeper right now since I'm on vacation but you can override CSS as a quick fix:

.tingle-modal {
    backdrop-filter: none;
}

[ghost]

Thanks @robinparisi, I'll try that -- but the support for backdrop-filter looks about the same or less than position:sticky according to: https://caniuse.com/#feat=css-backdrop-filter. CanIUse says IE 11 has no support for position:sticky it but it seemed to work fine for me in Edge. Hard to tell what to do with this apparent bug but I appreciate the suggestion!

[robinparisi]

Indeed, but I consider backdrop-filter as an optional enhancement (you can still achieve the same blur effect without it).

Modal position is trickier: I don't know why position: sticky allows to fix the Chrome 78 bug but it doesn't seem logical to me. I will try to understand this behavior and push a fix after my vacations.

[robinparisi]

After doing some research, it seems that Chrome has the correct implementation for position: fixed (https://developer.mozilla.org/en-US/docs/Web/CSS/position):

The element is removed from the normal document flow, and no space is created for the element in the page layout. It is positioned relative to the initial containing block established by the viewport, except when one of its ancestors has a transform, perspective, or filter property set to something other than none (see the CSS Transforms Spec), in which case that ancestor behaves as the containing block. (Note that there are browser inconsistencies with perspective and filter contributing to containing block formation.) Its final position is determined by the values of top, right, bottom, and left.

It explains why the div with backdrop-filter now act as a containing block.

[robinparisi]

I just published a patch using a pseudo-element to avoid modifying the parent container.