Jetpack: Slideshow: double left and right slideshow arrows appearing on WordPress.com Simple sites

Created on 3 Aug 2020  路  22Comments  路  Source: Automattic/jetpack

I noticed today that the left and right slideshow arrows are doubling up suddenly:

Screen Shot 2020-08-03 at 1 47 16 PM

I'm not sure where each set is coming from or why they are doubled.

[Block] Slideshow [Pri] High [Status] In Progress [Type] Bug [Type] Happiness Request

Most helpful comment

D47922-code has been shipped.

All 22 comments

This CSS will hide the larger arrows without the background:

.swiper-button-prev:after, .swiper-container-rtl .swiper-button-next:after {
    content:""
}

.swiper-button-next:after, .swiper-container-rtl .swiper-button-prev:after {
    content:""
}

Reported in #3198149-zen

I bet it's Swiper library update in Jetpack 2 days ago: https://github.com/Automattic/jetpack/pull/16587

cc @kraftbj @jeherve

I'll transfer this to Jetpack since that's where the block's source code is.

There are few breaking changes mentioned in 5.x and 6.x in the changelog: https://github.com/nolimits4web/swiper/blob/master/CHANGELOG.md

Would be good to check if e.g. color-varible changes affect us, in case we were overriding any defaults (or thinking if it's worth overriding since it could break in future again).

I wasn't been able to reproduce it in the Jetpack site. It seems like WPCOM specific.

I cannot seem to reproduce in Jetpack right now, even when using the Gutenberg plugin; this only seems to be an issue on WordPress.com.

I wonder if this may be a by-product of how our build tools work on WordPress.com; files are never removed by the TeamCity task that updates the build artifacts, so we keep old files around forever.

I've created D47600-code to fix things up a bit, but that's not solving our issue here (and I think we may have to update the way we do things so we don't have to clean up like this).

Looking at the build artifacts, on WordPress.com I see things like this:

.swiper-button-prev:after, .swiper-container-rtl .swiper-button-next:after {
    content: "prev";
}

But I don't see that in Jetpack build artifacts.

The 2 builds seem really different from each other, and I don't know why. There are no differences in package.json, webpack.config.extensions.js, or yarn.lock in the 2 environments.

Still looking.

Related discussion: p1596626293298400-slack-CBG1CP4EN

Does the swiper bundle on .com get hash or is it without hash? If without, it could be cache issue with older version of CSS sticking in cache and newer version of markup. Then it could also be issue in jetpack sites with more aggressive cache mechanisms.

Does the swiper bundle on .com get hash or is it without hash?

With the hash (and the correct one, from what I can tell).

I wonder if these path updates have generated different bundles:

https://github.com/Automattic/jetpack/pull/16587/files#diff-b41e2b8aacf8404d14a7d9dbf5e413b9L43-R46

I don't have much knowledge on Webpack dynamic imports... reaching out to Team Calypso might help since they're our Webpack experts.

https://webpack.js.org/api/module-methods/#import-1

Encountered on 23163569-hc

I ran into this, and an issue with the Fade transition effect making it so the images don't transition correctly:

https://github.com/Automattic/wp-calypso/issues/44723

Another report here 3202279-zen

@kraftbj would it be possible to revert back to previous version of Swiper library until issues are fixed?

Currently this looks pretty broken on people's sites:

Screenshot 2020-08-06 at 18 22 10

cc @lessbloat in case Manage focus can triage this as well (it's a visual breakage in slideshow block)

I have another issue of this on a simple site. The double arrows appear, and also the images don't transition well and some of the previous image still shows as the new image appears, looking like an overlapped image.

Screen Shot on 2020-08-06 at 12-44-15

22293720-hc

3203732-zen

Another report in 3209766-zen

Another of the duplicates and image overlap on Fade mode in #23042840-hc

Note: This can be seen on an internal P2: pc6Vrl-2j-p2

Another report in #3213658-zen

I have been able to replicate this issue on a local Jetpack dev site as well as simple WordPress.com sites. Using the Jetpack Beta plugin on an Atomic site, the issue isn't present when using the latest stable version but it is there on bleeding edge. Whether the Gutenberg plugin was active or not didn't make a difference either.

D47922-code still needs deploying for simple sites to get the fix.

D47922-code has been shipped.

Was this page helpful?
0 / 5 - 0 ratings