1788031 - Product images are in a loading loop on icbtechscr.com with ETP set to Strict

Status: RESOLVED INVALID

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Calin Tanase]

Attachment: icbtechscr.png

Environment:
Operating system: Android 11 (ONEPLUS A6000)
Firefox version: Firefox Nightly 106.0a1-20220829094551

Preconditions:
• ETP set to STRICT
• Clean profile
• US VPN might be needed

Steps to reproduce:

1. Go to https://www.icbtechscr.com
2. Scroll down the page.
3. Observe the product images.

Expected Behaviour:
The product images are displayed correctly.

Actual Behaviour:
The product images are not displayed, the images are in loading loop.

Notes:

1. Screenshot provided
2. Not reproducible with Standard ETP
3. Same behaviour in Private window

Comment 1

[Thomas Wisniewski [:twisniewski]]

This reproduces for me with ETP off as well. And I don't see anything interesting being blocked by ETP, but I do see this error in the console:

Uncaught TypeError: can't access property "end", $.support.transition is undefined

That's in this code:

  Carousel.prototype.pause = function (e) {
    return e || (this.paused = !0),
    this.$element.find('.vc_right.vc_carousel-control, .vc_left.vc_carousel-control').length && $.support.transition.end && (this.$element.trigger($.support.transition.end), this.cycle(!0)),
    this.interval = clearInterval(this.interval),
    this
  },

I don't see any sign of $.support having a transition property. In Chrome it is in this script, transition.min.js:

/*!
 * WPBakery Page Builder v6.0.0 (https://wpbakery.com)
 * Copyright 2011-2020 Michael M, WPBakery
 * License: Commercial. More details: http://go.wpbakery.com/licensing
 */

// jscs:disable
// jshint ignore: start

!function($) {
    "use strict";
    $.fn.emulateTransitionEnd = function(duration) {
        var called = !1
          , $el = this;
        return $(this).one($.support.transition.end, function() {
            called = !0
        }),
        setTimeout(function() {
            called || $($el).trigger($.support.transition.end)
        }, duration),
        this
    }
    ,
    $(function() {
        $.support.transition = function() {
            var el = document.createElement("bootstrap")
              , transEndEventNames = {
                WebkitTransition: "webkitTransitionEnd",
                MozTransition: "transitionend",
                OTransition: "oTransitionEnd otransitionend",
                transition: "transitionend"
            };
            for (var name in transEndEventNames)
                if (void 0 !== el.style[name])
                    return {
                        end: transEndEventNames[name]
                    }
        }()
    })
}(window.jQuery);

This script is loaded after the error trips for me, so this is a timing/race condition issue. They load the scripts in the correct order:

<script type='text/javascript' src='https://www.icbtechscr.com/wp-content/plugins/js_composer/assets/lib/vc_carousel/js/transition.min.js?ver=6.2.0' id='vc_transition_bootstrap_js-js'></script>
<script type='text/javascript' src='https://www.icbtechscr.com/wp-content/plugins/js_composer/assets/lib/vc_carousel/js/vc_carousel.min.js?ver=6.2.0' id='vc_carousel_js-js'></script>

But notice that the transitions library is waiting for $(function() { before it defines $.support.transition? The code to load the carousel is instead using window load events:

  $(window).on('load', function () {
    $('[data-ride="vc_carousel"]').each(function () {
      var $carousel = $(this);
      $carousel.carousel($carousel.data())
    })
  })

There is no guarantee which order these two will fire in, since jQuery's "ready" function also listens for window.load:

  function B() {
    E.removeEventListener('DOMContentLoaded', B),
    C.removeEventListener('load', B),
    S.ready()
  }

So it races against both, and if it happens to be window.load which fires first, there's no guarantee which of the two functions will be run first. Changing the code to use $(function() { as well instead fixes the problem. So this is really site error, per the standards. I don't believe even Chrome guarantees the order these events will fire in, so it's likely they're experiencing intermittent failures on other browsers as well.

Let's close this bug and reopen the webcompat.com one for needs-contact, as this isn't really a Firefox issue.