WAIT: Different font sizes on mobile (Android)

Bugs
1

Bricks Version: 1.6.1
Browser: Android (not sure about ios)
OS: Various mobile browsers (but some are worse than others)

Hey all,

Firstly, I hope you all had a fabulous Christmas and new year!

I messaged the Support email twice using different accounts (just in case there was an issue with one going through) about 4 or 5 days ago but had no response. I also direct messaged @timmse 3 days ago and had no reply either…very strange. (perhaps @luistinygod @thomas are on leave?)

Anyways, has anyone experienced corrupt output on mobile in terms of text breaking into two lines or text being different sizes even though it is the same size in the builder? Equally, the builder shows the correct size on the mobile viewing panel, but on the phone itself, it isn’t correct.

But please find two video recordings; the first is a side-by-side where I display the builder and my mobile mirrored. The Second is a screen recording directly on my mobile (sound quality is better, for better understanding).

Video 1 (desktop/mirror) = Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

Video 2 (mobile) = Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.

Has anyone experienced similar?

Also, if anyone has any spare time, could someone confirm if they see the same on their phone too (browser/phone model)

https://www.dev.wdsaigon.com

HTTP Authentication
Username: Dev
Password: 123abc

Many thanks in advance

Mick

1 Like
2

All looks fine on my mobile device and when running the page through browser testers, most likely cause is just caching on your mobile so you’re seeing an older version of the stylesheet when the text was perhaps larger.

When I inspect the code through my mobile, the exact same CSS is being applied to both texts. (the font size being --fs-base which is clamp(1.6rem, 0.3vw + 1.49rem, 1.9rem)

Note that ‘vw’ means viewport width, so there’s always going to be some tiny difference on the size based on the different screen widths. But no difference between the two different paragraphs that you pointed to.

1 Like
3

Hey David,

Thanks for taking the time out to have a look.

To discount the cache element I pushed the staging site to my main site as cannot wait my last site was on v1.5 which has the security vulnerability.

But the same issue persists some text smaller than others even though they are the same.

Also I appreciate the vw side and I’m aware of that but it would be very minimal where this is noticeable.

If it is done via an emulator such as Dev tools or in the builder it shows correctly. But not on a physical device.

I do not have a browserstacks subscription which would probably be the best debugging tool to be fair.

Ps do you or anyone else know of a Dev tool but for mobile browsers?

Thanks again for checking David

4

For Mac/iPhone I just plug it the iPhone into my MacBook and use devtools through Safari to inspect it through the phone, but this specific issue can’t be seen on iPhone anyway. I’m not sure about other mobile devices, if they have similar dev-tools capabilities with PCs.

2 Likes
5

Hey Mick,
The problem may be related to your font size settings on your Android device. In the past, there were problems with Android phones that enlarged or reduced text at will. I can’t say for sure if this is still the case, as I am also an iPhone user. But maybe this thread on StackOverflow will help:

Currently, we’re applying it only to the HTML :thinking:

Best regards,
timmse

6

Hey Stefan,

I do not think that would be the issue, as that would most likely apply to all the text and not random pieces.

Equally, the other part is the strange letter & word breaks found mainly in the footer (thus why I originally titled the ticket a little more vaguely and not just related to font size).

I am trying to find some patterns, and from what I can see, it seems to be an issue with the basic text element. (Font size and random breaks). It does also seem to affect the icon box and list element too. However, the Rich text element seems to work 100%

Hopefully, that will give you a starting point.

I am not sure if you guys have a BrowserStack subscription as part of your debugging stack, but I have DM you a new login link that might uncover something.

Many thanks

Mick

7

Yes, but the beaver is crying:

CleanShot 2023-01-16 at 22.48.41@2x
CleanShot 2023-01-16 at 22.48.41@2x2880×1528 297 KB

1 Like
8

I think you’re going to have to follow this - Remote debug Android devices - Chrome Developers

To inspect using dev tools through Chrome on your computer, to see what CSS is being applied when the site is being viewed on your android device. If there’s some default browser CSS there, you’ll see it when inspecting the element.

9

Damn that pesky beaver haha!

But he only shows up when a ‘dodgy’ character tries to access the site! :stuck_out_tongue_winking_eye: :rofl:

Just added Germany to the allowed list, mate. :slight_smile:

@wplit This is very cool to know! Thank you so much for the heads-up!

10

Hey @stefan

Just checking up on this as noticed no one logged in the last 7 days after granting access to your location.

Either way, managed to uncover more solid information thanks to @wplit solution. You can see from the screen recording that it is being computed differently. It turns out the smaller text is actually correct and its the larger text that is wrong (so most of the site is wrong on mobile haha).

Anyways, please find a local screen record which I had to upload to my one drive to share.

Many thanks

Mick

11

Did you try the original suggestion of ignoring the font size setting by changing the ‘text-size-adjust’ to none?

From your video, it’s at 100%, meaning “Enables the browser’s inflation algorithm… a percentage value with which to increase the font size.”

I don’t know why it would be targeting all the text apart from the text inside the links, but this is very likely what is happening as the official definition of what that CSS property does describes what you’re experiencing…

“The text-size-adjust CSS property controls the text inflation algorithm used on some smartphones”

12

Hi David,

I haven’t because there is no pattern of what is affected, It targets text in and outside of links. So it would be strange that that would be the cause.

Happy to check this; however, What would you advise I add this to make it site-wide? Would I have to target each root HTML such as this?

p, h1, h2, h3, h4, h5, h6 {
text-size-adjust: none;
}

Many thanks

Mick

13

Hey Mick,
Sorry, I was unavailable for a couple of days due to personal reasons.

Basically, targeting the HTML and body should be enough. Alternatively, you could try the asterisk “*” selector.

html,body {
  text-size-adjust: none;
  -webkit-text-size-adjust: none;
  -moz-text-size-adjust: none;
  -ms-text-size-adjust: none;
}

Best regards,
timmse

1 Like
14

No worries at all, bud and no need to apologise, I did see your inactivity, which was why I didn’t push.

Sending love and strength to you if needed mate!

Many thanks

Mick

15

Thanks, mate!
Does the provided CSS make any difference on the issue?

16

It doesn’t unfortunately, I left it a couple of days in case any residual cache but still the same.

Shall I ping you over a new login link?

17

Yes, please send it to me again. If I can see a problem on my Android tablet, at least I have a starting point. If not, it will be difficult…

18

I finally managed to take a look at this. I connected my Galaxy Tab via USB debugging. The result is that the font sizes differ.

But: this is definitely related to the fluid font-sizes (clamp) and potentially other factors. If I remove the body font variable and set it to a fixed font-size (or leave it blank), everything is fine.

I suspect that the clamp function on Android just works a little differently in certain scenarios. I can’t say why, but when I use the same clamp function on any of my sites, the font size is the same everywhere. So there seem to be some other factors (flex? padding? margins? min, max, whatever) at play…

Maybe you can reproduce the problem in a very simple installation without much bells and whistles?

Best regards,
timmse