Skip to content
This repository has been archived by the owner on Jan 15, 2021. It is now read-only.

Glimpse not detecting ajax request done in $(document).ready() #397

Closed
jmazurpl opened this issue Jun 20, 2013 · 14 comments
Closed

Glimpse not detecting ajax request done in $(document).ready() #397

jmazurpl opened this issue Jun 20, 2013 · 14 comments

Comments

@jmazurpl
Copy link

Glimpse is not detecting the ajax requests made in $(document).ready(). If I trigger the same ajax request for example with button everything is detected as it should.

@avanderhoorn
Copy link
Member

Just wondering where Glimpse is not detecting this? I am guessing that you aren't seeing it show up in HUD and that if you went to the Ajax tab you would see it there?

If this is correct, unfortunately this could be a timing thing. HUD currently only wires itself in on $(document).ready(). This means that there is a chance that some requests will be missed. Ideally, Glimpse would setup a buffer to start catching any requests that occur prior to this, but that isn't there currently.

Let me know if this looks like what you are seeing.

@jmazurpl
Copy link
Author

Yes this happens in the HUD, sorry for not mentioning that.

@nikmd23
Copy link
Member

nikmd23 commented Jun 28, 2013

Could the XHRequest wiring be done before $(document).ready()? I'm assuming that since it isn't (what I consider) part of the DOM that we might be able to tap into it sooner?

@avanderhoorn
Copy link
Member

Yep thats exactly what is happening. It is possible to capture some more scenarios than what we are getting now. To do so, we would need to Glimpse would setup a buffer to start catching any requests that occur prior to this, but that isn't there currently.

@nikmd23
Copy link
Member

nikmd23 commented Jul 1, 2013

@avanderhoorn, when you say Glimpse would need to buffer, does that mean:

  1. buffer the outgoing requests or
  2. buffer the incoming responses in case there is a response before the DOM is ready?

Or something else?

@avanderhoorn
Copy link
Member

@nikmd23 Both. At the moment we capture the request as its happening and when its finished, render it to the DOM. The problem with this approach is that if the HUD DOM isn't ready, because we are catching requests in flight, we have no where to put it.

The proposed change would mean that instead of losing the request in this case, we would put the request data into a buffer/array and when the HUD DOM is ready, it would look to see if there is anything in the buffer and if so render those requests straight away. From then on in, we would render to the DOM like we do at the moment.

Does that make sense?

@nikmd23
Copy link
Member

nikmd23 commented Jul 2, 2013

Yep, got it now! Thanks

@umairishaq
Copy link

I would like to work on this issue. Suggestions about a starting point, please?

@avanderhoorn
Copy link
Member

@umairishaq sounds good to me.

So there are a couple of things that will need to be looked at:

  • HUD doesn't detect early requests it hooks in once HUD is rendered. This is a problem because as others have pointed out, requests can occur before this point.
    • The relevant code is here.
    • If you shifted it to here, that would get into the pipeline earlier.
    • Only problem is that the update method isn't available in that scope and even if it was, HUD mightn't be rendered yet.
      • Hence, you will need to have a check which sees if things are ready yet and if not stores the required data in an array
      • From here, when you do render things, you can see if there is anything there yet, and if so, render it out

@nikmd23
Copy link
Member

nikmd23 commented Jul 16, 2014

Thanks @umairishaq!

@NickLarsen
Copy link

You can execute an ajax request at anytime, so the only real way to capture all requests is to do some initialization at the top of the file that is guaranteed to be the first thing executed. The first valid place for this is as the first child of the head element and you would have to inject script content there, not as a link. Technically you'd also have to ensure that glimpse is the last tool in your pipeline that injects html before sending it to the browser, but you can safely ignore that most of the time.

@avanderhoorn
Copy link
Member

@NickLarsen Agreed with this. Glimpse v2 will do things differently on this front. Hence making sure we can capture everything that happens.

@avanderhoorn
Copy link
Member

Note, if someone wants to make the change for the v1 client, I'm happy to help with the effort.

@mpetito
Copy link

mpetito commented Jun 19, 2015

@avanderhoorn, I've been tinkering with this issue for v1. My thoughts are to attach the ajax listener in a separate script loaded somewhere in the document head. The listener will reference the pubsub module and a stub will be included to queue up requests until the glimpse client is loaded. Once the glimpse client is loaded, the stub pubsub is replaced and queued messages are delivered as the corresponding subscriptions are registered. I've made these changes to the client (including a new glimpse.head.js file) here: https://github.com/mpetito/Glimpse.Client/commit/2ba16d2502c463a1381c1091f6b4563574da11cf

I've tested these changes by modifying the glimpse.js resource in Glimpse.Core and manually adding glimpse.head.js to the document head.

One potential issue with this approach is that ajax requests initiated after the pubsub module loads, but before the hud module's postRender method subscribes to ajax.update, will not be observed.

I'm also not sure how best to include the new glimpse.head.js file in the document head. Glimpse.Core.Framework.IFrameworkProvider.InjectHttpResponseBody expects a single htmlSnippet for inclusion using Glimpse.AspNet.PreBodyTagFilter. It seems that, in addition to the embedded script resource classes in Glimpse.Core, IFrameworkProvider needs another method for InjectHttpResponseHead?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants