It's "a bit" complicated.
In some situations, getRuns get's called because listeners on bounds are set.
This causes TextFlow to layout to compute the runs.
Afterward, the bounds of the parents get updated.
This triggers a call to compute bounds - which cascades up to the children.
When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
In the case it happened - it didn't repair and the application kinda crashed.
This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
It also can cause unpredictable performance issues.
Unit test and example stacktrace are in the ticket.
In some situations, getRuns get's called because listeners on bounds are set.
This causes TextFlow to layout to compute the runs.
Afterward, the bounds of the parents get updated.
This triggers a call to compute bounds - which cascades up to the children.
When the geometry of the previous Text gets computed in this big stack - it throws an nullpointer.
The Text doesn't have its runs, and calling TextFlow.layout is now a noop (it detects repeated calls in the same stack)
In the case it happened - it didn't repair and the application kinda crashed.
This bug most likely can also be triggered by ScenicView or similar tools, which sets listeners to the bounds.
It also can cause unpredictable performance issues.
Unit test and example stacktrace are in the ticket.