The jQuery written for Floating Block works well on desktop environments, but has issues on iPads and Android tablets. Users on these devices tend to scroll very quickly through a page, and the CPUs are not powerful enough to handle the recomputation required for a floating block. Also, iPad does not calculate position of elements based on the scroll position, but rather when the page stops scrolling.

These factors cause unintended consequences to the user experience. At a minimum, the block will "jump" from one spot to another as a user scrolls through the page. In worse situations, we actually see distortion of the block, where it will break out of its container or scroll off the page and not be reaccessible.

The key issue in all of this is jQuery. It's an overlay to JavaScript, and therefore not nearly as fast as using native JS. To have this module work more effectively on iPads and Android tablets, the floating_block.js code should be made much more efficient than it is today, or should be written directly in JavaScript rather than jQuery.

As well, review this post regarding the use of "position: sticky" in WebKit: http://updates.html5rocks.com/2012/08/Stick-your-landings-position-stick... Obviously not a solution for all browsers, but provides some thought about the future of such features. Also see the feedback under "Why JS is not ideal" regarding hardware accelerated scrolling, and the issues perceived by users with floating items.

Comments

mikeker’s picture

mikeker CreditAttribution: mikeker commented

I realize that I'm commenting on an issue that's had no action for the last six months, but I don't think it's jQuery that's causing the problems you're seeing...

The key issue in all of this is jQuery. It's an overlay to JavaScript, and therefore not nearly as fast as using native JS.

I'd like to see some benchmarks before we throw the baby out with the bathwater. :) Poorly written jQuery is less performant than well written JavaScript, but saying jQuery is "not nearly as fast" as native JS is incorrect.

My comparison shows only 1 or 2 percent more CPU usage when scrolling the same page with and without floating block enabled. (This is an admittedly highly unscientific comparison -- I took a long page and ran the scroll bar up and down while watching the CPU meter).

re: tablets: modern Android browsers (>= 2.3, if memory serves) correctly handle scroll events, but doesn't repaint correctly. Android >= 4.0 does both correctly and the UX is exactly the same as a desktop browser. Webkit browsers on the iPad still do not fire onscroll correctly -- they wait until the scroll movement and momentum has stopped. Regardless, CPU limitation wouldn't be a factor if the scroll event is only called once instead of a few 100 times.

re: CPU- vs. GPU-accelerated scrolling: That's a fair concern, especially if you're doing image parallax or something fancy like that. If so, the fix may be to force those events to use the GPU (transform3d, if available or transform2d if not). A CSS-only solution (position: sticky) would be lovely and wouldn't interfere with GPU accelerated redraw, but is only available for Safari out of the box.

Old thread, I know, but I'd be interested in hear if I'm off target. Drupal core's tabledrag uses the same methodology so this could be the root of a bigger issue in some scenarios.

Jonathan_W’s picture

Jonathan_W
he/him
Primary language English
Location Omaha, NE, USA
CreditAttribution: Jonathan_W commented

Is it possible that the "jumping" is related to this issue here?: https://www.drupal.org/node/2256415#comment-9586695

kopeboy’s picture

kopeboy CreditAttribution: kopeboy commented

I just tested on an iPad Pro (13") with Safari and I can confirm the issue.

I have jump links on the "floating" part of the page, linking to anchors in a long table on the same page.

  • If I click on a jump link, they stay visible (i.e. the block in correctly floating), BUT
  • if I scroll the page normally, the floating block goes immediately up and disappear from the page.

dqd’s picture

dqd
(formerly "diqidoq")
CreditAttribution: dqd as a volunteer and at MAROQQO studios commented
Status: Active » Closed (outdated)

Thanks for reporting. Closed because outdated and reported 5 years ago without recent activity while cleaning up the issue queue. Feel free to re-open for a newer version if this issue still persist. Apart from that, note that jQuery will be removed from core asap.