ajax-loading and attached libraries

Hi Wim.

Thanks for taking the time to reply so quickly!

I don't understand why this is a same-origin problem though. I don't get any 403's, and I thought that the CDN module already has this solved with the headers sent to (in my case) amazon.

Also I don't have any problems with normal page loads getting whatever they need from cloudfront. Also, post-ajax-request, I do have succesful hits to cloudfront (image attached showing this).

Is there something different about an ajax request that I'm not thinking about?

Thanks!

Okay so I looked through the js and css files that DID get downloaded and tried to compare against the render array to try to find a pattern...

I'm not 100% positive, but it looks like there's a pattern!
- The files that ARE NOT working are attached as a "library"
- The files that ARE working are attached either as "css" or as "js".

I attached any libraries that are needed by the ajax call to the original page, and it seems to work around it.

In light of this new information, I'm tempted to switch this back to bug-report, since I don't see anything in the docs relating to library attachments vs css/js. But I don't want to be rude ;-).

Although I've already worked around this, this has been a thorn for me, so I'm still digging...

It looks like there's another pattern:

Files that DO NOT work are also all either augmented or replaced via the bootstrap theme's _js_alter hook.

This seems to be a more likely suspect, since looking through the code seems like the library thing shouldn't make a damn bit of difference.

Sigh. Couldn't find the cause yet.

Okay I gotta give up on this for now. Maybe I'll be able to probe further later. For now I'm just working around it.

Can you disable that theme for a moment (or at least its alter hook) and see what difference that makes?

Lol! I wish I'd thought of that before spending an hour or two digging through code! I'll try that as soon as I'm in the context of chasing this down again. I actually had no idea that the bootstrap theme swaps out and adds to some of the core javascript files. At least I learned that in the process.

And yes, I agree - this looks like something non-CDN-friendly that the bootstrap theme is doing. And thank you again for taking the time to help!

Sorry Wim. None yet. I got sucked into a hundred other things on the project. I forgot about this because I had the workaround of pre-loading the javascript :(.

But thanks for the reminder. I'll try to look into it again as soon as I can.

Sorry it took so long.

I tried the following:
- Switched the theme back to Bartik
- Switched jquery update to the drupal default
- Disabled advanced aggregation

...and I still see the behavior:

unless I add the following to the render array of the original page:

$retval[9]['#attached']['js'][] = 'misc/tabledrag.js';
$retval[9]['#attached']['library'][] = array('system', 'drupal.collapse');

...ajax-loaded tabledrags (e.g. field collections) don't show up properly (they show raw weights instead of the tabledrag).

When disabling CDN, it's not necessary to brute-force load those on the original page.

It looks like I read us up the wrong tree with the bootstrap stuff :(. But at least we eliminated those things.

When it's failing, I look at the javascripts being downloaded upon the ajax call, and I do see the tabledrag stuff being downloaded. So it's weird that it's not working.

So I took everything back to my production state and pasted a couple screenshots of the network tab (this time Edge's). The files fetched are exactly the same size in the CDN and no-CDN cases. The only difference there is the "initiator" column - in one case it says XMLHttpRequest and in the other it says "script". Not sure why.

Both cases have no errors on the console when you hit the ajax call. This is absolutely bizarre.