"misc/progress.js" is not being included when "Aggregate JavaScript files." is used

FYI: I, too, came to this report since I was seeing the same conditions (aggregate js, misc/progress.js missing) but in my case it was how file permissions were set on the server that prevented was the cause of my issue (apache error logs reported permissions issues with that directory.)

http://petermoulding.com/:
The first file is Drupal Ajax. The second file is a collection of jQuery UI, superfish. The third is the progress.js. Could the split be caused by the source of the files?
<script type="text/javascript" src="http://petermoulding.com/sites/default/files/js/js_UnvjlDWluTdpMZX0r-R6e..."></script>
<script type="text/javascript" src="http://petermoulding.com/sites/default/files/js/js_FVY1YtSeRh5ohfr81KjZ9..."></script>
<script type="text/javascript" src="http://petermoulding.com/misc/progress.js?1321352097"></script>

system.module:
'js' => array('misc/progress.js' => array('group' => JS_DEFAULT, 'cache' => FALSE),
ctools/includes/modal.inc:
drupal_add_js('misc/progress.js');

Could the double addition end up with progress.js in a different group to everything else?

System.module puts the libraries in several groups and we end up with 3 js files instead of one. progress.js could be in a different file because of the ctools request or because system.modules uses a different combination. Perhaps system.module could start by merging JS_SYSTEM and JS_DEFAULT. ctools could stop the separate request.

Having the exact same issue here, running drupal 7.9, results of the JS aggregation on the site:

<script type="text/javascript" src="[SITE]/sites/default/files/js/js_FZukR_GTwi8gFmCBoNJY8mcSk7XaX7T28PMrLUB8mKk.js"></script>
<script type="text/javascript" src="[SITE]/sites/default/files/js/js_l3G0-7fsR8jRIfktlkpgd5R1eujRXGUF3zmWpa-rxwo.js"></script>
<script type="text/javascript" src="[SITE]/sites/default/files/js/js_RFk7q9PTKBwqdtieABZFabpusp6lYAihH42qsMaI11I.js"></script>
<script type="text/javascript" src="[SITE]/misc/progress.js?1322627877"></script>
<script type="text/javascript" src="[SITE]/sites/default/files/js/js_MJwqLqptsSWTRZdguWzwAbSipjvxCIyA-r0hLNIwMDw.js"></script>
<script type="text/javascript" src="[SITE]/sites/default/files/js/js_z7FAbL5rUJCXNJvd3aPw9Qo93Ch6CuJ4IRvt_eyRM1U.js"></script>

Any reason why this file is bundled outside on purpose? Or would a simple patch just tell it to be aggregated?

Attached is a patch that aggregates progress.js into the other JS bundles.

I have no idea if this is a good idea in the bigger picture (it is for our usecase), or whether there has been some decision to not aggregate this particular library on purpose (in system.module). Perhaps a core maintainer/developer could chip in here to explain.

now rolled without --no-prefix and --relative

Example of un-patched production and the miss-aggregation of the progress.js file -> http://www.health.govt.nz/

This was changed in 7f8b191781017f2212ca547b8d0e1fac7990e9a4 (#119441: Compress JS aggregation), but I'm not sure why.

That thread also includes a fix for when progress.js is added in update.php, where the intention is that it should NOT be cached. It appears that that fix somehow leaked into this bit and has stuck around since:

@@ -66,7 +66,7 @@ function _batch_progress_page_js() {
   $current_set = _batch_current_set();
 
   drupal_set_title($current_set['title']);
-  drupal_add_js('misc/progress.js', 'core', 'header');
+  drupal_add_js('misc/progress.js', 'core', 'header', FALSE, FALSE);

I can't imagine why we'd want to force progress.js to not only not be aggregated, but not be cacheable. Attach patch remedies this.

My guess would be that someone temporarily mistook 'cache' for 'preprocess' while re-rolling the patch.

Looks RTBC to me so marking as such, I don't think we need a test for this one - you'd have to look for the file in the aggregate or something else nasty and fragile. Will commit in a few days if no objections.

Committed/pushed to 8.x, will need a quick re-roll for 7.x.

Could this make it into 7.11? It is working and is not that complex I guess

MyXelf

@MyXelf If you review the patch can put youself the reviewed & tested by the community state.

Changing the status as suggested. I'm always thinking this kind of things shouldn't be done by merely mortals like me :-) Thanks!

@MyXelf, Drupal is developed by 14,613 mere mortals. (Plus me :-)) Thats what makes it so strong and useful.

Committed and pushed to 7.x. Thanks!