I assume he 304 response does have a Content-Type header that indicates some character encoding other than UTF-8?  Could you please provide a chrome://net-export/ log of both the functional and then the broken requests?  Instructions:  https://dev.chromium.org/for-testers/providing-network-details

Cookies and other credentials will not appear in the log, but requested URLs and proxy configuration will.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Ok, got more information now.

I configured two instances.
The difference is in Cache-Control headers's max-age

The problem is occurring on the instance where I have set the max-age to 30 seconds (or less)

Because that's when the 304 or 200 (from memory cache) occurs
and hence the issue.

The 2nd instance loads with 200 (from disk cache) and it's all fine.

Attaching both the two files for the instance with the issue:
First load (fresh) [chrome-net-export-log-ok.json]
After refresh [chrome-net-export-log-issue.json]

Deleted: chrome-net-export-log-ok.json 433 KB

chrome-net-export-log-ok.json 433 KB View Download

Deleted: chrome-net-export-log-issue.json 197 KB

chrome-net-export-log-issue.json 197 KB View Download

What's the URL for the resource with the text?

triager tentatively assigning the bug.

The text is created via JS, below is the URL
http://static.qa.careem-engineering.com/signup/js/app.js

Sorry, not my area

Hrm...So the fact that whether or not the resource is cached rather strongly suggests this is a caching issue, but there's no HTTP content-type header with a character encoding, and the network stack doesn't sniff character encoding, so I think this may be an issue with the blink in-memory cache, rather than the on-disk HTTP cache.

Also, loading the Javascript file directly, I see the strings interpreted as Latin-1 (I assume), rather than UTF-8, for both cached and uncached loads, further indicating the issue isn't related to getting the HTTP headers wrong on reloads.

If you restart chrome and navigate to the page page again, does the page work for the first load (While also getting a 304 response)?  I'd test myself, but I'm not sure how to get to that page.  Just navigating to http://static.qa.careem-engineering.com/signup/en/, the pulldown looks to consistently show arabic correctly.

Yes the JS files are not being served with a charset they inherit from the html.
In all of the tries I made, I have found whether it's 200 or 304, whenever it's from memory-cache, it has the issue.

As I mentioned earlier I have another similar setup, the only difference, the max-life is 3 hrs instead of 30 seconds, so due the the long life it's never from memory-cache, but disk-cache and the issue doesn't occur.

Two key points for this issue to happen:
1. Caching should be enabled.
2. Should be done within 30 seconds of the previous load to get a 304 or even sometimes a 200 (from memory cache)

In my opinion max-life being around 30 seconds is an edge case that escaped. As it's not very practical to cache usual resources for 30 seconds, in that case most people would just disable the caching.

IIRC Chrome guess the character encoding for the first certain size of readable data if the encoding is unclear. That first readable size will depend on the situation if it is from cache or not, and that affects the detection result.

So, I think this works as intended.

Ok. So it's guessing the wrong encoding when it's from memory-cache only?

Yeah, I think so. Generally speaking, when data comes from the memory cache, more data will be available for encoding detection, but it may result in a wrong guess in your case.

http://static.qa.careem-engineering.com/signup/en/
But, if the html file you said is this, it looks the page contains <meta charset="utf-8">. So the problem may not an encoding issue, but a font issue. It looks the Arabic characters in your first screenshot seems to use a WebFont, Careem, in a right case. How about the failed case? I could not confirm it because the problem can not reproduce on my local machine.

The failed case happens when you refresh within 30 seconds.
cache should be enabled
and the response should come from memory-cache.

I'm on version 65.0.3325.181 (Official Build) (64-bit)

On my local machine, even after a quick reload and data come from the memory cache, the Arabic characters are rendered correctly below the EN.

Can you check the used font on the failed case?

On DevTools, you will see the 'Square and Cursor' icon on the top-left side. Click the icon, and select the target area, broken Arabic text. Once selected, you will see a pain that has tabs, Styles, Computed, and so on at the right side. Select the Computed tab, then scroll down if it has a scroll bar. At the bottom, Rendered Fonts area explains the used fonts in the selected area.

If this is not 'Careem - Network resource (7 glyphs)', something is wrong on font loading.

You're right it's different.

Without issue:
Careem—Network resource(7 glyphs)

With issue:
Arial—Local file(10 glyphs)
Careem—Network resource(4 glyphs)

Hum... but it looks Creem-Network is also available even in the failed case. So, the font looks correctly loaded, and was available at the rendering time.

This indicates it isn't a fond loading issue, but an encoding issue as we guessed first.

Needs helps from a ScriptLoader's expert.

If the reporter can create a minimized repro test case, that would help investigation very much. At this point, it is unclear how the top page is dynamically constructed, that may be related to the issue, e.g. the script may be loaded before the meta charset is specified.

Is this issue 441781?

Seems like it.

Then let's talk about this issue there.