From 3d38db2a658cfd24848ab6204cb82614161428e0 Mon Sep 17 00:00:00 2001
From: =?utf8?q?Bartosz=20Dziewo=C5=84ski?= <matma.rex@gmail.com>
Date: Wed, 13 Feb 2019 14:21:04 +0100
Subject: [PATCH] resourceloader: Restore the comment about <script> vs XHR
 loading

Removed in 42956b99b558294e5aa8c6c0e2a8f18513478022.

I think it's useful to know this rationale (even more so because
the arguments about caching seem no longer correct these days).

Also, add the line about loading progress not being known when
using this method.

(Slightly related to T216034)

Change-Id: I81fa90483c0c85fecc5cb620196521ce8bdd33a7
---
 resources/src/startup/mediawiki.js | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/resources/src/startup/mediawiki.js b/resources/src/startup/mediawiki.js
index b5ba6a66a6..65cf3169bb 100644
--- a/resources/src/startup/mediawiki.js
+++ b/resources/src/startup/mediawiki.js
@@ -1102,6 +1102,12 @@
 			 * @param {Function} [callback] Callback to run after request resolution
 			 */
 			function addScript( src, callback ) {
+				// Use a <script> element rather than XHR. Using XHR changes the request
+				// headers (potentially missing a cache hit), and reduces caching in general
+				// since browsers cache XHR much less (if at all). And XHR means we retrieve
+				// text, so we'd need to eval, which then messes up line numbers.
+				// The drawback is that <script> does not offer progress events, feedback is
+				// only given after downloading, parsing, and execution have completed.
 				var script = document.createElement( 'script' );
 				script.src = src;
 				script.onload = script.onerror = function () {
-- 
2.20.1