views:

313

answers:

3

Hi there,

thank you for taking the time to read my question.

I have significantly rephrased my question after some new findings.

My problem is that in my ajax callback, when I set the context of my query to be the returned html of my ajax call, it cannot find any elements.

Some findings:

  1. The problem never occurs in Firefox
  2. The problem only occurs in IE when logged in as a user in SharePoint with a certain amount of permissions, causing certain extra html to be generated to facilitate administrative functionality. I have come to the conclusion that it is this extra html that is causing the problem.

Unfortunately I am not in control of the html generated, as it is generated by SharePoint.

I have isolated the problem and created a simple test page for you to look at.

Any ideas?

Thanks ever so much!

A: 

from what i understood you might want to try the "selector in the url syntax" to reload only specific parts of the page

$("#somediv").load(location.href + " #somediv");

plus, add a random parameter to avoid cache issues:

$("#somediv").load(location.href + "?r=" + Math.random() + " #somediv");
stereofrog
@stereofrog, thanks but I only want to make 1 ajax request. If I have 10 of these divs on my page, I don't want to call load() 10 times, if you see what I mean.
Jaap
A: 

I cannot see anything in firefox, and that is because this bit in your code is wrong:

google.load("jquery", "1.2.6");          //ok
google.setOnLoadCallback(function() {    //ok
   $(document).ready(function()          //not ok, can't be sure if will fire
      {  
         // great stuff here 
      }
   );
});

See this for clarification, document might be (indeed in firefox is) already be readed when the LoadCallback from google is called.

If you can please correct that bit we can further investigate it with firebug to see where the script is broking.

Alex Bagnolini
thanks Alex, that is useful information. I removed the document ready handler, and now it does find an img element. I now need to come up with a better example that demonstrates my problem, since the example now doesn't suffer from the problem I was describing.
Jaap
I have noticed that I now get the expected behaviour but only when I am running the page anonymously - when I am authenticated (basic authentication), that's when it behaves strangely! Let me see if I can create a user account for you to login with so you can see what I mean.
Jaap
hmmm. So I did create a new user, but I have now found out that it does not matter whether you are authenticated or not, but it's the level of permissions in SharePoint. All I can think of, is that when I load the page as an admin, it will include certain html/javascript to facilitate the administrative interface. Could it perhaps be that something on the page makes it unqueryable or something?
Jaap
Please reread my question at the top of the page since I have significantly rephrased it after new findings.
Jaap
+4  A: 

The problem is in how jQuery instantiates html passed to it, possibly lacking a good cross-browser string-to-dom parsing technique (such as createContextualFragment on Mozilla).

To be concrete, there are two regexes in the jQuery's clean function which will have to be fixed:

857: var match = /^<(\w+)\s*\/?>$/.exec(elems[0]);
874: elem = elem.replace(/(<(\w+)[^>]*?)\/>/g, function(all, front, tag){

Both of these will fail to process tags with colon in the name.

The fix:

857: var match = /^<([\w:]+)\s*\/?>$/.exec(elems[0]);
874: elem = elem.replace(/(<([\w:]+)[^>]*?)\/>/g, function(all, front, tag){
einaros
Here's a patched (unminified) jQuery js: http://dl.getdropbox.com/u/1878671/jquery-1.3.2-fixfornastynodes.js
einaros
That fixed it! wow thanks! Although It would be cool to have a more unobtrusive fix so I don't have to ship the modified jquery library with my solution.
Jaap
Well you could always preprocess the html string before passing it on to jQuery. Inefficient, but it would work.
einaros
Yep! Sounds like a good enough approach to me! Thanks :)
Jaap
I filed a bug: http://dev.jquery.com/ticket/5358 and just landed a fix for the problem: http://dev.jquery.com/changeset/6617 The change will be in an upcoming nightly and in jQuery 1.4. Thanks for spotting this!
John Resig
Cool! Thanks for that John :)
Jaap