Bug? Weird behaviour of text blocks

Hi community!

Today we have encountered a very strange behaviour on one of our landing pages.
For reference, this is the published page: https://triathlon.vation.io/
My colleague and I both encounter the following behaviour:
The text loads (four bullet points) in the correct format. VEEEERY briefly you see it as Times New Roman before, but I believe this is just your browser showing you the text before the fonts are loaded.
This is all fine.
Some very few milliseconds after the correct font has been applied (Montserrat in this case),
the first of the four bullet points kind of “condenses”. The correct term should be “kerning”.
This results in different formats for the bullet points. We used the “inspect” function in Chrome and detected, that for whatever reason, that the element.style contains two “transform” options.
If you delete them in Chrome, the format is shown in the intended way. Please refer to the following two screenshots (or reproduce this behaviour in your browser):

So the question remains: how do we solve this issue. While we do use some javascripts and CSS on the webpage, none of them refer to the text boxes. Or at least, we believe so. Here is the CSS:

    <style type="text/css">
#lp-pom-root .lp-pom-text a:link {text-decoration: none}
#lp-pom-root .lp-pom-text a:visited {text-decoration: none}
#lp-pom-root .lp-pom-text a:active {text-decoration: none}
#lp-pom-root .lp-pom-text a:hover {text-decoration: none}
.shadow-effect {
    background: #fff;
    padding: 20px;
    border-radius: 4px;
    text-align: center;
    border: 1px solid #ECECEC;
    box-shadow: 0 19px 38px rgba(0,0,0,0.10), 0 15px 12px rgba(0,0,0,0.02);

#testimonials-list .shadow-effect p {
    font-family: Montserrat;
    font-size: 15px;
  	color: #1A1A1A;
    line-height: 1.5;
    margin: 0 0 17px 0;
    font-weight: 300;

.testimonial-name {
    margin: -17px auto 0;
    display: table;
    width: auto;
  	font-family: Montserrat;
  	font-size: 17px;
    background: #1A1A1A;
  	opacity: 0.6;
    padding: 9px 35px;
    border-radius: 12px;
    text-align: center;
    color: #fff;
  	font-weight: 600;
    box-shadow: 0 9px 18px rgba(0,0,0,0.12), 0 5px 7px rgba(0,0,0,0.05);

#testimonials-list .item {
    text-align: center;
    font-size: 24px;
    padding: 50px;
    margin-bottom: 80px;
    opacity: .2;
    -webkit-transform: scale3d(0.8, 0.8, 1);
    transform: scale3d(0.8, 0.8, 1);
    transition: all 0.3s ease-in-out;

#testimonials-list .owl-item.active.center .item {
    opacity: 1;
    -webkit-transform: scale3d(1.0, 1.0, 1);
    transform: scale3d(1.0, 1.0, 1);

.owl-carousel .owl-item img {
    -webkit-transform-style: preserve-3d;
    transform-style: preserve-3d;
    max-width: 90px;
    border-radius: 50%;
    margin: 0 auto 17px;

#testimonials-list.owl-carousel .owl-dots .owl-dot.active span,
#testimonials-list.owl-carousel .owl-dots .owl-dot:hover span {
    background: #1A1A1A;
    -webkit-transform: translate3d(0px, -50%, 0px) scale(0.7);
    transform: translate3d(0px, -50%, 0px) scale(0.7);

#testimonials-list.owl-carousel .owl-dots {
    display: inline-block;
    width: 100%;
    text-align: center;

    #testimonials-list.owl-carousel .owl-dots .owl-dot {
        display: inline-block;

        #testimonials-list.owl-carousel .owl-dots .owl-dot span {
            background: #1A1A1A;
            display: inline-block;
            height: 20px;
            margin: 0 2px 5px;
            -webkit-transform: translate3d(0px, -50%, 0px) scale(0.3);
            transform: translate3d(0px, -50%, 0px) scale(0.3);
            -webkit-transform-origin: 50% 50% 0;
            transform-origin: 50% 50% 0;
            transition: all 250ms ease-out 0s;
            width: 20px;

I have found one workaround, which - interestingly - worked for a short time:
In the text box preferences I switched to “heading 6” from “paragraph”.
This solved the issue temporarily, but now it has reappeared.

Does anyone have an idea what we are doing wrong or what is even going on? :slight_smile:

Thank you very much in advance!

1 Like

Hey @Marcel_Heymuth! I’ve looped in the @UnbounceTechTeam to take a quick look at this and make sure there isn’t something wonky going on. Stay tuned!



the Unbounce tech-team has been quick as usual and has provided us with a solution.
Somehow, there was a malfunction of the builder. Including the following script in the section seems to solve the issue:

window.ub.page.disableTextAdjustments = true;  

Thanks for the quick support, guys!


Thanks for this! Been fighting this bug for a long time and didn’t know this was a property we could set.

I was able to replicate it when I am using dynamic text and the parent element contains a font-size attribute. Once I remove font-size, the incorrect text adjustments don’t get added. Once I add font-size, the text adjustments get added.

1 Like

@Jess I just had this same issue occurring. The script has fixed it, but just FYI :slight_smile:

1 Like

@Zoe_Tattersall That’s no bueno! I’ll check and see if they have plans for a larger fix :female_detective:


Alright, here’s what I heard back from our dev team:

The original issue here is that different browsers on different OSs render fonts slightly differently and this was causing paragraphs to wrap on different words. Because everything on the page is absolutely positioned, this could cause text to overlap other page elements and look like a real mess. So the text adjustment algorithm was added to try to prevent these differences, but clearly there are some bugs with it (like what’s shown in the screenshots above).

Earlier this year (during the jQuery upgrade) we did investigate whether we could remove the adjuster completely, or disable it by default, but we found that it was still preventing wrapping differences in Firefox on Windows and possibly other browsers. I think we decided not to remove it since doing so might actually cause more customer issues than the amount we’ve been seeing with it on.

That said, it doesn’t look like it’s in the pipeline to be worked on at the moment. I suggest continuing the use the solution shared above, and I’ll update here if I hear of any movement on this.


1 Like

No worries! This is the first time I’ve seen this, and after I finally figure out what it was (2 hours later), the fix is easy :slight_smile:

1 Like