[Android] fontSize styles on nested Text elements aren't always applied

[artemiswkearney]

Description

On Android devices, large Text components will sometimes fail to apply the fontSize property of nested Text component's styles, resulting in text rendering with the parent's font size.

These lines of text all have the same style, but render at different sizes.

(Haven't tested whether this applies to things besides fontSize. When scrolling through the text, the bug seems periodic, happening to the last few Texts out of every group of some larger number.)

Version

0.67.3 (originally observed on 0.64.1)

Output of npx react-native info

info Fetching system and libraries information...
System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 Intel(R) Core(TM) i7-10750H CPU @ 2.60GHz
    Memory: 2.65 GB / 15.76 GB
  Binaries:
    Node: 17.7.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.5 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 8.5.2 - C:\Program Files\nodejs\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK: Not Found
  IDEs:
    Android Studio: Not Found
    Visual Studio: 16.10.31402.337 (Visual Studio Community 2019), 15.9.28307.1033 (Visual Studio Community 2017)
  Languages:
    Java: 1.8.0_282 - C:\Program Files\OpenJDK\openjdk-8u282-b08\bin\javac.EXE
  npmPackages:
    @react-native-community/cli: Not Found
    react: 17.0.2 => 17.0.2
    react-native: 0.67.3 => 0.67.3
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

Steps to reproduce

1. Render a large number of Text components, each with their own style props including fontSize values, inside a Text component with a different fontSize
2. Deploy your app to an Android device
3. Observe that some of the text is rendered with the wrong font size

Snack, code example, screenshot, or link to a repository

https://snack.expo.dev/IbMg-oQqi
Measures the height of various Texts using onLayout events, then computes how far off the height of a large nested Text is from its expected height. Constants at the top of the file:

• USE_DIFFERENT_HEIGHTS: If true, the newlines in between phrases will be rendered at a smaller font size. Seems to make the bug happen at lower phrase counts, but isn't required.
• NUM_PHRASES: The number of phrases to render. On my test phone and on the Snack Android device, 52 seems to be the minimum number to reproduce with USE_DIFFERENT_HEIGHTS off, 37 with it on. Use higher values like 200 to see the periodic effect mentioned earlier.
• THROW_IF_WRONG_HEIGHT: If true, throws an error if the height is too far from the expected value. Otherwise, just console.logs about it.

[artemiswkearney]

Also occurs for lineHeight.

[fai9al7dad]

same problem here

[cubuspl42]

I created a MCVE for this issue. It's a simple app that contains multiple nodes with a simple text "abc".

const text = "abc";

function App(): JSX.Element {
  return (
    <SafeAreaView>
      {section(5)}
      {section(10)}
      {section(15)}
      {section(20)}
      {section(84)}
      {section(85)}
      {section(86)}
      {section(87)}
      {section(88)}
    </SafeAreaView>
  );
}

const section = (size: number) => (
  <View>
    <Text>Section with {size * text.length} characters</Text>
    <Text style={{
      "color": "red",
    }}>
      {[...Array(size).keys()].map(innerText)}
    </Text>
  </View>
);

const innerText = (index: number) => (
  <Text
    key={index}
    style={{
      "color": "blue",
      "fontWeight": "bold"
    }}
  >
    {text}
  </Text>
);

We can see that the styling starts behaving unexpectedly when the whole text becomes longer than 255 characters.

I started to investigate this issue in React Native's source, and that number is by no means accidental. I'll post more results soon.

[Szymon20000]

I checked the pr and it makes a lot of sense.
Also tested it in RNTester on paper arch and wasn't able to spot any difference.
As I'm not the author of the original code so I'm not able to tell what was the reason for using priorities this way.
However, I guess the purpose was to make sure that children operations are executed after parents.
I don't know any example of span operations that would be broken by this approach.

I'm not sure though if we really need to use priority. From what I see spans are sorted first by priority then by insertion order. I guess it wasn't the case when the code was created.

aosp-mirror/platform_frameworks_base@fa05ba0

Maybe we can set the same priority for span operations and insertion order will handle the rest (we also need to call Collections.reverse(ops) as we want to apply parents first)?

[cubuspl42]

@Szymon20000 Thanks for your thoughts. Doesn't this belong to the PR, though?

[Szymon20000]

It does. A bit tired today!
Copied!