Flexslider image size issue in Firefox: How to debug?

What to do when one browser displays your Flexslider images incorrectly, even though they look alright in others? My reflections about Flexslider image size issue in Firefox:

Incorrect image size in Flexslider - problem summary

Flexslider displays the images incorrectly in certain circumstances. In our case, the images look fine in Chrome:

but in Firefox, they are too big:

Let’s find out why this happens. First, let’s have a look at an inspector to detect any potentially suspicious CSS and so on.

Let’s compare single slide styles in Chrome vs Firefox side by side. In Firefox, the width assigned inline is much higher.

What does it mean that the CSS property is inline? It most likely means that it’s created by Flexslider’s JS which comes minified with WooCommerce. It’s not our code. Opening the debugger will help us investigate the problem!

How to open a debugger?

Since Flexslider is not our JS, we can’t just open it in the editor like any other project file. I mean, we can, but it’s minified and hence completely illegible. That’s why we need to open the browser debugger.

Debugger in Chrome browser

Let’s go to Sources and find the file you’d like to debug.

Debugger in Mozilla Firefox browser

Firefox has a Debugger tab that does basically the same thing.

How do debug?

As you can see, the script is minified. Both Chrome and Firefox have this { } icon:

Click it to un-minify the code:

Note that the variables will all be terribly named. The file was minified so the variables have been given one-character names for shortness. In result, the browser won’t be able to offer meaningful names in their place.

You can set a breakpoint by clicking a number of the line:

Now, if you refresh the page, JS will stop executing at a given point:

In the browser window:

In the debugger window on the right:

Additionally, you can hover over variables now to see their values:

Chrome and Firefox browsers display slightly different things. For example, Chrome will not make it possible to hover over objects under undefined. Also we may only be able to preview code that has already been executed.

Flexslider image size issue: Problem at hand

Okay, so now we’ll have to find a place in the file that creates this inline CSS, namely width and float. My guess is that the word width is used very often so we won’t get far searching by it. Let us try with float. And surely, two occurrences are found:

There are some hardcoded values here, so it’s not it. The next float is way below:

There, you can see that this is where computedW is being assigned. Now, let’s find out where it comes from. We know that variables are assigned with =, so let’s find computedW =:

Let’s see if there’s a difference between Chrome and Firefox:

Ok, we're onto something!

It looks like this value is calculated by something. Let’s search for the source of itemW:

The value is calculated by a long and complex equation. Additionally, the code is minified. All the variables are named by a single letter (e.g. t) instead of their regular descriptive names like slideWrapper. We don’t even know what they stand for.

Simplify the complicated

Alright, it all seems pretty complicated but probably we can handle it. For starters, there are plenty of calculations. I don’t want to lose time figuring it out so I look further to hopefully find something simpler. Ternary ends:

Look, it sets something simple - just h.w. Cool, maybe it’s nothing bad. Let’s look for the definition.

Nice, it doesn’t look complex at all. It either takes width from h, or from h.viewport. At this point, I don’t even know what h or h.viewport actually is. The code is minified and the names aren’t very helpful but for now, it’s enough to know that it’s something that sets width in CSS.

Let’s see if h.w differs between Chrome and Firefox.

Fine, but what h and h.viewport actually are?
I can hover over it in the debugger:

Here we get HTML elements. This is h. I can even click the element under 0 and it will take me to that element in the inspector. It turns out that h is the entire slider and h.viewport is an element inside the slider with a .flex-viewport class.

Since we have a series of thumbnails on the left, then the whole slider (h) that contains these thumbnails and the main image is wider than the image itself (h.viewport).

It leaves us with one more question. Why does Firefox apply the wrong width here? This time we’re lucky because just one line below we can see:

If isFirefox is set, then it always takes the width of the entire slider and not just the viewport. I can’t think of any good reason for why would it act that way.

What's next?

Unfortunately, Flexslider doesn’t check if some elements exist or if there’s a feature in Firefox, nothing. Using Firefox? You have a problem.

We can also see that isFirefox is set just based on user agent, and not e.g. a slider option, so we can't switch it off.

So, is there no good fix for Flexslider image size issue?

Not to end it with a cliffhanger, here are two solutions:

1. (worse) Replace Flexslider that comes with Woo with a custom JS that has isFirefox set to false.
2. (better but more time-consuming) Redo the slider in Woo products so that there are two sliders instead of thumbnails squeezed inside a single slider and positioned with styles, causing calculations issues.