iOS8 Safari does not support getBoundingClientRect

[kianoshp]

This results in the "fixed-supported" class being removed from the html tag and as a result fixed sticky not working properly. We have temporarily added iOS8 Safari to the list of user agents skip the feature test. I can also add a pull request that will do exactly what we have done.

[beep]

Having this issue on iOS8 as well. (Webviews inside apps seem unaffected.)

[niksy]

@kianoshp I’ve created the pull request for this issue. If you already have it somewhere else (or have better test for this) I will remove it and leave it to you.

[kianoshp]

@niksy I created the following pull request:

#6

I will leave it up to the filament group to evaluate which is more appropriate.

[emilbjorklund]

I'm not sure exactly how iOS8+ screws up getBoundingClientRect, but after some quick testing (in iOS9), it seems it will vary the top value while scrolling – possibly related to toolbars or something. Maybe that's why @beep finds different behavior in WebViews? ¯_(ツ)_/¯

Anyhow, if getBoundingClientRect is wonky in iOS8+, I thought it might be worth to just do some UA sniffing / inference to force a positive, so I did this: https://gist.github.com/emilbjorklund/e796da508d1f5d006cac

It checks for /iPad|iPhone|iPod/ UA string + not having window.MSStream (to rule out IE on Windows Phone having iPhone in UA string) + having window.indexedDB (as that was introduced in iOS 8).

[emilbjorklund]

Some further detail on this:

• iOS 8-9 does support Element.getBoundingClientRect(), but it is buggy (tested on 8.4 and 9.0.1, iPhone 5S in both cases). Hence the title of this bug is not really correct. Let me know if I should open a new bug.
• The bugginess comes from giving the incorrect value of top while scrolling – it is as if the element coordinates are position: absolute while scrolling, but as soon as the scroll stops, ”correct” value is reported (see next bullet for definition of ”correct”).
• Despite the scroll stopping, the reported top value of the tested element is sometimes -1 instead of 0.
• I've managed to get a reasonably correct value by wrapping the position check in a debounce-function, thus waiting until the scroll stops. This works something like 90% of the time – sometimes, it just doesn't seem to get it (most often while scrolling to the bottom or top, so potentially has to do with the ”bouncy” stop in Mobile Safari. If I run the debounced check a few times and save the results in an array, I'd typically get a result like [0, -1, 0, 0, -1, -63, 0, -1].
• Hypothetically, this could be a usable check: run the test a few times, discard any values over a certain threshold etc, and check if the rest are 0 or -1.

That last bit seems kinda smelly to me, so maybe just whitelisting iOS via UA-sniff is the better way to go.

[kianoshp]

@emilbjorklund 💯