Update "emulation.setLocaleOverride" to also override "Accept-Language" header.

[lutien]

In the relation with "network.setExtraHeaders", my approach was that "emulation.setLocaleOverride" always takes precedent and overrides the values which might be set with "network.setExtraHeaders", since clients, when they use "emulation.setLocaleOverride", probably want locale values to be aligned across APIs. But let me know if I missed some use case scenarios.

---

Preview | Diff

[sadym-chromium]

In the relation with "network.setExtraHeaders", my approach was that "emulation.setLocaleOverride" always takes precedent and overrides the values which might be set with "network.setExtraHeaders", since clients, when they use "emulation.setLocaleOverride", probably want locale values to be aligned across APIs. But let me know if I missed some use case scenarios.

I would expect the emulated locale not to be distinguishable from the one selected by the user, but this behavior creates an observable difference in emulated and non-emulated locale behavior.

[sadym-chromium]

Also the Fetch spec adds Accept-Language only if it is not yet set. E.g.:

await fetch(..., {headers: { 'Accept-Language': 'SOME_STRING' }})

In this case overriding the user's 'Accept-Language' headers can mask some issues, like fetch in JS code mistakenly sending a wrong Accept-Language header.

I believe the better approach would be to define "an appropriate Accept-Language header value" in fetch, step 12.

[lutien]

Also the Fetch spec adds Accept-Language only if it is not yet set. E.g.:

await fetch(..., {headers: { 'Accept-Language': 'SOME_STRING' }})

In this case overriding the user's 'Accept-Language' headers can mask some issues, like fetch in JS code mistakenly sending a wrong Accept-Language header.

I believe the better approach would be to define "an appropriate Accept-Language header value" in fetch, step 12.

Yeah, I think it makes sense. I've created a PR for the fetch spec. I've reused the hook added for navigator.language, and I think nothing has to be done here. So I'm going to close this PR.

@sadym-chromium, could you also create an issue for this feature? (I need for the PR check list)