Affix doesn't update in iOS UIWebview

[mhemesath]

In UIWebview scroll events aren't fired. This has the effect of making affix look buggy as its position isnd't updated until after scroll is done. To mitigate the effects of this, we could add a touchmove event listener to update the affix position when the user is scrolling via moving their finger.

    this.$target = $(this.options.target)
      .on('scroll.bs.affix.data-api', $.proxy(this.checkPosition, this))
      .on('touchmove.bs.affix.data-api', $.proxy(this.checkPosition, this))
      .on('click.bs.affix.data-api',  $.proxy(this.checkPositionWithEventLoop, this))

[cvrebert]

What version of iOS are you using?

[mhemesath]

iOS 8.2. You can reproduce the issue in Chrome for iOS

[cvrebert]

Does http://stackoverflow.com/a/10880812 not work?

[mhemesath]

That doesn't solve the issue. The view can scroll, it just doesn't fire any scroll events while it is going. This causes the affix to not "stick" until after scroll ends.

[cvrebert]

Does WKWebView suffer from the same problem?

[mhemesath]

No, I haven't tested it but from what I've read the WKWebview is similar to the native Safari in iOS 8.X and will throw scroll events while scrolling. This is only a a problem for UIWebview in iOS.

[cvrebert]

Okay, have you tried https://poschel.wordpress.com/2013/08/29/uiwebview-javascript-scroll-events-in-ios-7/ ?

[cvrebert]

@mhemesath Have you gotten a chance to try the other workaround I linked to above?

[mhemesath]

Sorry, that didn't seem to work either. We are getting scroll events, just not until after scroll is over. I can try to throw together a test page that should be reproducible with Chrome on iOS (which uses webview I think).

[cvrebert]

Can you post what the UIWebview uses as its user agent string?

For comparison:

• iOS 8.3 Safari
  • Mozilla/5.0 (iPhone; CPU iPhone OS 8_3 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Version/8.0 Mobile/12F70 Safari/600.1.4
• OS X Safari 8.0.5
  • Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/600.5.17 (KHTML, like Gecko) Version/8.0.5 Safari/600.5.17

[mhemesath]

Mozilla/5.0 (iPhone; CPU iPhone OS 10_10_2 like Mac OS X) AppleWebKit/600.1.4 (KHTML, like Gecko) Mobile/12D508

[cvrebert]

So, my research didn't turn up any way to differentiate between UIWebView vs. WKWebView via JS.
UIWebView can be distinguished from Safari by looking for the "Version/" token in the user agent, which is present in Safari but absent in both types of webview.

@fat What are your thoughts here, given the possible performance penalty of a touch event handler?