Tested only on s390x (big endian) on the 68 ESR codebase:

When entering an URL into the URL bar, the moment the text doesn't fit into the textbox anymore (URL gets too long), the bar turns white (all text disappears).
Other HTML-textboxes seem to work fine. This only happens in the URL-bar.

Investigation so far:

I removed everything from browser.xul that isn't the URL-bar and activated MOZ_DUMP_PAINT.
Then, I copied out the Surface: data:image/png;base64-part of the logs and saved them as attachments.

I see two things in the logs:

1. As long as the text fits into the textbox, the text gets rendered directly into the one existing Surface (see working.png). As soon as I type one character too many, there are now 2 Surfaces, one containing only the text, the other all the rest without any text (see notworking.png, where the surfaces are separated by a plus-sign).
   Surface "the rest" does look exactly as the error-case, so I'm guessing the merge of these two Surfaces somehow fails.

2. Once the one-too-many-character gets typed, there appears a new item in the list of things to paint: CompositorHitTestInfo. Not sure, if that is in any way related or not.

I'm a bit at a loss where to continue searching, as there are no error-messages of any kind. So any help would be appreciated.

Once again, a hack instead of a solution.
The problem seems to be an alpha-mask. Removing it from the pipeline makes the URL-bar behave normally.
Will continue a bit to investigate, if I can actually fix this instead of working around it.

(In reply to msirringhaus from comment #0)

1. As long as the text fits into the textbox, the text gets rendered directly into the one existing Surface (see working.png). As soon as I type one character too many, there are now 2 Surfaces, one containing only the text, the other all the rest without any text (see notworking.png, where the surfaces are separated by a plus-sign).
   Surface "the rest" does look exactly as the error-case, so I'm guessing the merge of these two Surfaces somehow fails.

When the text grows too long, we have to start support scrolling for that surface, which might include using additional intermediate surfaces.

2. Once the one-too-many-character gets typed, there appears a new item in the list of things to paint: CompositorHitTestInfo. Not sure, if that is in any way related or not.

CompositorHitTestInfo display items contain information about scrollable areas. They might also affect layerization on non-WebRender code path that you are hitting.

msirringhaus, could you enable pref layout.display-list.dump-parent and attach the display list and layerization for short (working) and long text (broken case)?

A couple of other things you could try:
Comment out line https://searchfox.org/mozilla-central/rev/923eec8d2fb8078ebc7a33a9e1ce73eac01f7446/layout/painting/nsDisplayList.cpp#2774
and replace the condition in https://searchfox.org/mozilla-central/rev/923eec8d2fb8078ebc7a33a9e1ce73eac01f7446/layout/generic/nsFrame.cpp#3360 with true. This disables some performance optimizations that might affect scrolling and layerization.

Finding a regression range for this would also help in case this was already fixed at some point.

So, I did try out your suggestions, but to no avail.

However, I managed to narrow down the bug.
This line
https://searchfox.org/mozilla-central/rev/6bceafe72cad5d5752667b4b6bd595d3a4047ca3/layout/painting/FrameLayerBuilder.cpp#7510
seems to be broken on big endian.

I dumped the surface of MaskImageData (format SurfaceFormat::A8) before and after this call, both on s390x and x86_64.
It starts with all zeros on both platforms.
On x86_64, it is predominantly 0xff after aClip.FillIntersectionOfRoundedRectClips(), whereas it stays mostly zeros (== all pixels transparent) on s390x.

Commenting out this line on x86_64 (thus forcing it to zeros) gives me the same error (white URL-bar) as on s390x.

As far as I have understood it, this layer should just provide the URL-bar rectangle with rounded corners. But if broken, it seems to force all pixels to become transparent, not just the corners.

Unfortunately, for some reason this layer does not get created when starting Firefox in a debugger (the error disappears). So I can't debug this properly, but have to resort to printf-debugging, which is much slower.

The old patch does not work anymore for FF73.
This is an updated patch/hack, which works.

Still haven't found an actual fix for this.