In the case of attachment 9018795 [details], it looks like we're not auto-detecting the (utf-8) encoding. It displays the expected emoji if you manually select the encoding in Firefox (View menu > Text encoding > Unicode).

(Otherwise, whether it works may depend on the system locale, as I think this affects what fallback encoding we'll try to use for content that doesn't declare one.)

Henri, I think you know about encoding detection, iirc; is it expected that we'd detect this example as utf-8, or do we not attempt to do this automagically for such content?

emoji.html is unlabeled UTF-8. For me both latest Firefox and Chromium load it as UTF-8 (emoji shows) from a file: URL and as windows-1252 (emoji doesn't show) from an https URL. When loading from an https URL, choosing View: Text Encoding: Unicode makes the emoji show.

The distinction between file: and https: is expected: We don't detect UTF-8 on the Web, because doing so reliably would be incompatible with incremental rendering and doing so unreliably would still cause authors to fail to label the encoding and would make the Web Platform more brittle overall.

emoji_works.html is UTF-16LE with BOM, so it works both from file: and https: (additionally, Bugzilla also sniffs the BOM and adds the corresponding HTTP-level declaration).

The above is all behaving as expected.

Reporter, what action did you take that in Chrome caused the emoji to show but in Firefox did not cause the emoji to show? What action did you take that caused earlier Nightly to show emoji but later not? (That is, please state steps to reproduce with the level of detail that includes where you were loading emoji.html from in each case.)

(In reply to Henri Sivonen (:hsivonen) from comment #4)

emoji.html is unlabeled UTF-8. For me both latest Firefox and Chromium load
it as UTF-8 (emoji shows) from a file: URL and as windows-1252 (emoji
doesn't show) from an https URL. When loading from an https URL, choosing
View: Text Encoding: Unicode makes the emoji show.

The distinction between file: and https: is expected: We don't detect UTF-8
on the Web, because doing so reliably would be incompatible with incremental
rendering and doing so unreliably would still cause authors to fail to label
the encoding and would make the Web Platform more brittle overall.

emoji_works.html is UTF-16LE with BOM, so it works both from file: and
https: (additionally, Bugzilla also sniffs the BOM and adds the
corresponding HTTP-level declaration).

The above is all behaving as expected.

This describes exactly what I am seeing now on Nightly and Chrome. Therefore, either Chrome changed something, or I made changes in my system, or the May Windows Updated changed something on my system.

Reporter, what action did you take that in Chrome caused the emoji to show
but in Firefox did not cause the emoji to show? What action did you take
that caused earlier Nightly to show emoji but later not? (That is, please
state steps to reproduce with the level of detail that includes where you
were loading emoji.html from in each case.)

I had loaded the emoji.html file from both disk and bugzilla on Nightly. In both cases it would not render correctly. (I didnt change any view->encoding setting)
I had loaded the emoji.html file from both disk and bugzilla on Chrome. In both cases it would render correctly.

But now that I see exactly what you have described above, I am willing to fix this as resolved for some. Thank a lot for looking into it though!