1556507 - Precompressed gzip-files (javascript) are working with Chromium but not with Firefox

Status: NEW

(Core :: DOM: Networking, defect, P3)

Description

[damir.isanbirdin]

Attachment: Compare Chrome very well Rendering vs Firefox bug

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36

Steps to reproduce:

• precompress javascript file blah.js as blah.js.gz

Actual results:

• javascript will be not recongnized

Expected results:

render as JavaScript

Comment 1

[damir.isanbirdin]

Attachment: Console exceptions output - wrong MIME

Comment 2

[Luciana queirolo]

Hi,
Please, see if the issue is still reproducible on Nightly latest version, you can download it from here https://www.mozilla.org/en-US/firefox/nightly/all/
Also, could you please provide a example file?

thanks,

Comment 3

[damir.isanbirdin]

Attachment: Firefox bug

Comment 4

[damir.isanbirdin]

(In reply to Luciana queirolo from comment #2)

Hi,

Nightly build is buggy as well: precompressed js are not rendering. Firefox still thinks - there is gzip-file. But forget to think a futher step- it is javascript- MIME. Look a last screenshot I did. Tested with safari, opera, edge- works very well , but not Firefox....

I will provide a simple example.
But it is very simple to reproduce: gzip any js-file. Include this file in your html . If you are using offline- your file name must be be *.js after gzip. If you are using server etc *.js.gz

Regards

Comment 5

[damir.isanbirdin]

Hi,(In reply to Luciana queirolo from comment #2)

An example project:

https://github.com/damir78/frfxdemo

I'm using spring boot (java).

You can start as DemoApplication.java as main class or
using script mvnw on linux or mvnw.cmd on windows.

Try
http://localhost:8080/hello.html

Regards
Damir

Comment 6

[Rares Doghi, Desktop QA]

Hi, I managed to reproduce this issue on Windows 10 in our Latest nightly build 69.0a1 (2019-07-07), as well as Beta 68 and Release 67.0.4, I was using spring boot and the Demo from https://github.com/damir78/frfxdemo, after starting the DemoApplication.java and reaching http://localhost:8080/hello.html the Hello world prompt wouldnt be displayed like it is on Chrome or Edge.

I'm not sure what the correct component for this issue is, if its Javascript Engine or maybe File Handling but hopefully our devs can move it to the correct one. Thanks for taking the time to report this issue.

Comment 7

[Nicolas B. Pierron [:nbp]]

Andrea, any idea where this bug belongs and who might look at it?
My guess would be that this is related to the HTTP headers of the pre-compress JS file or to some automatic mime-type inference that Chrome does and not Firefox.

Comment 8

[Jason Orendorff [:jorendorff]]

Reproduced using this node script, in case anyone doesn't want to install Java.

This is definitely a MIME handling thing. I don't know what the right component is, but File Handling is closer than JavaScript Engine.

const gzipped_bytes = Buffer.from([
  31, 139, 8, 8, 245, 88, 39, 93, 0, 3, 116, 101, 115, 116, 46, 106, 115, 0,
  75, 201, 79, 46, 205, 77, 205, 43, 209, 43, 47, 202, 44, 73, 213, 80, 178,
  201, 48, 180, 203, 72, 205, 201, 201, 87, 40, 207, 47, 202, 73, 177, 209,
  7, 242, 149, 52, 173, 185, 0, 14, 85, 38, 26, 40, 0, 0, 0
]);

require('http').createServer((req, res) => {
  console.log(req.url);
  if (req.url == "/") {
    res.writeHead(200, {"Content-Type": "text/html"});
    res.write('<script src="test.js"></script>');
  } else if (req.url == "/test.js") {
    res.writeHead(200, {
      "Content-Type": "application/x-gzip",
      "Content-Encoding": "gzip"
    });
    res.write(gzipped_bytes);
  } else {
    res.writeHead(404);
  }
  res.end();
}).listen(8080);

Comment 9

[Andrea Marchesini [:baku]]

Jason, thanks for this test! So the issue is that we are actually treating JS differently because its content-type is not valid.
annevk, based on the mime-sniff spec, should we treat this JS as text/javascript, or we should ignore it (as we do)?

This sounds like a server-side bug, because the Content-Type should describe the content, and not the encoding.

Comment 10

[Anne (:annevk)]

The classic script loader does not care much for the Content-Type header (except for blocking on certain specific MIME types, such as text/csv). Bug 1030660 seems more suspect here. We probably need more tests to find out what other user agents do exactly in order to feel confident on changing our code around this.