Update progress meter should work

[arantius]

See #1053

When downloading a script update, currently the download meter never fills, it just appears empty, then at some later point disappears.

[arantius]

So! It was a little annoying to shfit things around so that enough progress data could flow where it needed to be, but rather straightforward. Once I did that, however, I started trying to actually track progress, and I can't find a way to download a file and (reliably) actually know how much of it has been downloaded, while the download is happening -- rather crucial for a progress meter.

The problem is basically that user scripts are text files, and likely to be gzip encoded. The only reliably "total length" data we have is the "Content-Length" HTTP header. In the case of gzip compression however, that number cannot be compared to the "length we've downloaded so far" and I get stuck.

[sizzlemctwizzle]

Use a progress listener?

var req = new XMLHttpRequest();
res.open('GET', 'script.user.js', true);
req.addEventListener("progress", function(evt) {
  var loaded = evt.loaded;
  var total = evt.total;
  var percentLoaded = Math.floor(loaded / total) * 100;
});
res.send(null);

[arantius]

In that case, "total" is the http-header-content-length value. In the example I was testing (very repetitive comment text) it was 1701, although the final "total" value was well over 400,000 (thanks to gzip decompression). That's exactly the problem I was describing.

Other tests with nsIWebBrowserPersist and its progressListener went better, but it's not consistently used in ScriptDownloader now. Thus #1458.

[sizzlemctwizzle]

Are the loaded and total values consistent in relation to each other? After all it's just relative. You just need a percent, right?

[arantius]

No. -Gzip is not deterministic.- Edit: the length output of gunzip is not a fixed ratio based on the length of its input, it depends on the actual content.

[sizzlemctwizzle]

And the evt.total is the length of the original file, not the gzipped file? And the value given by evt.loaded is how much of the gzipped file has been downloaded? If that's true then how does anybody get download progress bars right?

[Martii]

Just a note here... some servers aren't configured or capable of sending the file size on the request and basically a 0, 1, 2, 3, ... 100% meter is not always possible which is when the "cylon" (or some other names too rich for posting) meter is usually used. Since GM can install from anywhere this should be a factor to consider as well as dynamically generated scripts that don't know until they are finished.

#1451 might be a good mid to short term solution until this gets fully explored and developed.