<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: G.</title>
    <description>The latest articles on DEV Community by G. (@mouvedia).</description>
    <link>https://dev.to/mouvedia</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F95303%2Fed1d79f6-7b7d-49f5-b3e6-79f7114c06e7.jpg</url>
      <title>DEV Community: G.</title>
      <link>https://dev.to/mouvedia</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/mouvedia"/>
    <language>en</language>
    <item>
      <title>XMLHttpRequest onprogress chronicles</title>
      <dc:creator>G.</dc:creator>
      <pubDate>Thu, 10 Jan 2019 04:22:20 +0000</pubDate>
      <link>https://dev.to/mouvedia/xmlhttprequest-onprogress-chronicles-44c0</link>
      <guid>https://dev.to/mouvedia/xmlhttprequest-onprogress-chronicles-44c0</guid>
      <description>&lt;h2&gt;
  
  
  Preamble
&lt;/h2&gt;

&lt;p&gt;When you want to implement something in a cross-browser way, you are in for a ride down the bugtracker hole. After some &lt;del&gt;exhausting&lt;/del&gt;thorough research, I felt the urge to share my findings on &lt;code&gt;XMLHttpRequest.prototype.onprogress&lt;/code&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  Rationale—why fetch doesn't cut it
&lt;/h2&gt;

&lt;p&gt;Before going further, I'd like to explain why I prefer &lt;code&gt;XMLHttpRequest&lt;/code&gt; over &lt;code&gt;fetch&lt;/code&gt; for download monitoring: browser vendors didn't ship &lt;code&gt;Response.prototype.body&lt;/code&gt; from the get go i.e. &lt;strong&gt;&lt;code&gt;fetch&lt;/code&gt; didn't support it initially&lt;/strong&gt;.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;interface ProgressEvent : Event {
  readonly attribute boolean lengthComputable;
  readonly attribute unsigned long long loaded;
  readonly attribute unsigned long long total;
};
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;And &lt;em&gt;even&lt;/em&gt; if the browsers that you currently target do provide that readable stream, &lt;code&gt;XMLHttpRequest&lt;/code&gt; would remain the superior choice for an arcane discrepancy: when the &lt;code&gt;content-length&lt;/code&gt; response header is present &lt;em&gt;but not exposed&lt;/em&gt;, &lt;code&gt;total&lt;/code&gt; will be populated with the response body's size &lt;strong&gt;irregardless of the &lt;code&gt;Access-Control-Expose-Headers&lt;/code&gt; field's value&lt;/strong&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  Genesis
&lt;/h2&gt;



&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;interface LSProgressEvent : Event {
  readonly attribute unsigned long position;
  readonly attribute unsigned long totalSize;
};
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;Its first incarnation was implemented by Firefox 0.9.3! Back then the &lt;a href="https://www.w3.org/TR/progress-events/" rel="noopener noreferrer"&gt;&lt;code&gt;ProgressEvent&lt;/code&gt; interface&lt;/a&gt; didn't exist so they relied on the little known &lt;a href="https://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS-LSProgressEvent" rel="noopener noreferrer"&gt;&lt;code&gt;LSProgressEvent&lt;/code&gt; interface&lt;/a&gt;; to remain compatible WebKit had to support both interfaces until Mozilla finally dropped the latter.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;interface XMLHttpRequest : XMLHttpRequestEventTarget {
  …
  attribute EventHandler onprogress;
  attribute EventHandler onreadystatechange;
  …
};
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;For other browsers you had to fallback on &lt;code&gt;XMLHttpRequest.prototype.onreadystatechange&lt;/code&gt; which had its own &lt;a href="https://www.quirksmode.org/blog/archives/2005/09/xmlhttp_notes_r_2.html" rel="noopener noreferrer"&gt;shortcomings&lt;/a&gt;. Sadly, the native version of &lt;code&gt;XMLHttpRequest&lt;/code&gt; introduced in Internet Explorer 7 &lt;a href="https://msdn.microsoft.com/en-us/windows/ms534361(v=vs.71)#readystate_interactive" rel="noopener noreferrer"&gt;didn't expose partial results&lt;/a&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  Browsers' Defects
&lt;/h2&gt;

&lt;h3&gt;
  
  
  Mozilla
&lt;/h3&gt;

&lt;p&gt;Probably due to their early implementation, Gecko-powered browsers had many bugs to account for, notably:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;until version 9, the &lt;code&gt;addEventListener&lt;/code&gt; variant of &lt;code&gt;onprogress&lt;/code&gt; wasn't supported&lt;/li&gt;
&lt;li&gt;between version 3.5 and 8, you had to fallback on the &lt;code&gt;onload&lt;/code&gt; handler to compensate for the inane absence of the last progress event that used to be fired by &lt;code&gt;onprogress&lt;/code&gt; when it reached the 100% mark&lt;/li&gt;
&lt;li&gt;until version 34, when a &lt;code&gt;Content-Encoding&lt;/code&gt; response header field was present the &lt;code&gt;loaded&lt;/code&gt; property reflected the number of bytes &lt;em&gt;after&lt;/em&gt; decompression instead of the raw bytes transferred which resulted—if a &lt;code&gt;Content-Length&lt;/code&gt; was sent by the server—in &lt;code&gt;loaded&lt;/code&gt; exceeding &lt;code&gt;total&lt;/code&gt; once all the data was received&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Microsoft
&lt;/h3&gt;

&lt;p&gt;Internet Explorer 8 brought the non-standard &lt;code&gt;XDomainRequest.prototype.onprogress&lt;/code&gt;. Since it didn't pass any arguments to the callback you had to track &lt;code&gt;XDomainRequest.prototype.responseText&lt;/code&gt; from within the closure. We had to wait another 3 years for Internet Explorer 10 to finally support all XMLHttpRequest Level 2 events—progress included.&lt;/p&gt;

&lt;h3&gt;
  
  
  WebKit/Blink
&lt;/h3&gt;

&lt;ul&gt;
&lt;li&gt;if &lt;code&gt;lengthComputable === false&lt;/code&gt;—i.e. the &lt;code&gt;Content-Length&lt;/code&gt; response header is missing—&lt;code&gt;total&lt;/code&gt; and &lt;code&gt;totalSize&lt;/code&gt; used to return UINT64_MAX instead of &lt;code&gt;0&lt;/code&gt;
&lt;/li&gt;
&lt;li&gt;when the &lt;code&gt;Content-Encoding&lt;/code&gt; is set, &lt;code&gt;total&lt;/code&gt; erroneously returns &lt;code&gt;0&lt;/code&gt; even if the &lt;code&gt;Content-Length&lt;/code&gt; is positive&lt;/li&gt;
&lt;/ul&gt;

&lt;h3&gt;
  
  
  Opera 12
&lt;/h3&gt;



&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;interface XMLHttpRequest : XMLHttpRequestEventTarget {
  …
  void overrideMimeType(DOMString mime);
  attribute XMLHttpRequestResponseType responseType;
  …
};
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;For the &lt;code&gt;loaded&lt;/code&gt; property to be accurate relative to the &lt;code&gt;total&lt;/code&gt; property, the response body had to be treated as binary. To that end you had 2 possibilities:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;setting the &lt;code&gt;responseType&lt;/code&gt; to either &lt;code&gt;"blob"&lt;/code&gt; or &lt;code&gt;"arraybuffer"&lt;/code&gt;
&lt;/li&gt;
&lt;li&gt;tampering with the media type using &lt;code&gt;overrideMimeType&lt;/code&gt;
&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  Why?!
&lt;/h2&gt;

&lt;p&gt;If you are wondering why I know so much about these quirks, it comes down to me being the maintainer of &lt;a href="https://github.com/Mouvedia/cb-fetch/" rel="noopener noreferrer"&gt;cb-fetch&lt;/a&gt;, a &lt;strong&gt;cross-browser&lt;/strong&gt; HTTP client that abstracts away all this mess for you. Well it does way more than that, by all means check it out!&lt;br&gt;&lt;br&gt;
My goal is to reach &lt;strong&gt;100 stars&lt;/strong&gt; on GitHub before the next release.&lt;/p&gt;

&lt;h1&gt;
  
  
  Archaeology
&lt;/h1&gt;

&lt;p&gt;&lt;a href="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fypf16lti4w3y33n24443.jpg" class="article-body-image-wrapper"&gt;&lt;img src="https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fypf16lti4w3y33n24443.jpg" alt="student" width="" height=""&gt;&lt;/a&gt;&lt;br&gt;
I consider myself an API archaeologist. Do you like that kind of exhaustive examination of a subject? Does it belong on dev.to?&lt;/p&gt;

</description>
      <category>frontend</category>
      <category>javascript</category>
      <category>api</category>
      <category>webdev</category>
    </item>
  </channel>
</rss>
