Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upPreserve URL hash when requesting via $.ajax #1732
Comments
|
Comment author: pferreir I forgot to add that in the first case the element seems to be added to the DOM only to be immediately removed. |
|
Comment author: dmethvin Why not use $.getScript ? http://api.jquery.com/jQuery.getScript/ Can you provide a complete test case on jsfiddle.net? That would help us evaluate the problem. |
|
Comment author: pferreir Hello, Here is a small example: http://jsfiddle.net/RQVsa/ The uncommented code should work (show the "Like" button), while the commented on should fail. I tried $.getScript, with no success... |
|
Comment author: timmywil We filter out scripts in manipulation. getScript should be used, but we remove hashes from the url. I'm not sure why, but it's been there a while. |
|
Comment author: dmethvin Seems valid enough to keep open, until we figure out why we're removing the hash. |
|
Comment author: dmethvin Okay, this gives me an error from Facebook because of the xxx id: This gives the same error and doesn't have the hash as timmywil said: Since the script hasn't yet been executed the .insertBefore() is making the ajax request to request the script, but since the hash is stripped it's never going to see the correct id. @jaubourg, do you know why we're stripping off the hash? Is there a specific reason for it, or just an omission? |
|
Hmmm. Now that we are attempting to parse the URL a bit more sanely per gh-1875 it might be possible to preserve the hash now. |
|
By golly I think we can. After gh-1880 lands the hash is conveniently in |
|
This was unlocked by b091fdb, but we might want a distinct ticket for AJAX hash preservation. |
|
Agreed, since it's potentially a breaking change it's a good 3.0 candidate. |
|
Looking at the WHATWG XHR spec they have intentionally taken the hash (fragment) off the URL in the Edit: Additional info here seems to indicate stripping the fragment early is okay: https://lists.w3.org/Archives/Public/public-webapps-github/2015Jul/1046.html |
|
Fragments are never sent to servers, and are apparently not even exposed on fetches. But they can appear in the DOM and be visible to executing scripts. It's an extremely rare case to be sure, but one that script transports are technically wrong on as long as we strip them. |
|
Interesting. I asked a Stack Overflow question about this a while ago and never got a response. I'll add a link to this issue and the pull request to the question in comments. Thanks for working on this everyone! For reference, my question is at http://stackoverflow.com/questions/32855458/jquery-ajax-content-from-an-end-point-which-responds-differently-depending-on-th |
This hasn't been a problem for a long time and jQuery no longer removes the hash in 3.0.0, so the test started to fail even though the actual code is working just fine. Ref #3627 Ref jquery/jquery#1732
As of jQuery 3.0.0, hashes are no longer stripped for Ajax requests. This causes issues in IE <11, so we need to strip this before making the request. Ref jquery/jquery#1732
As of jQuery 3.0.0, hashes are no longer stripped for Ajax requests. This causes issues in IE <11, so we need to strip this before making the request. Ref jquery/jquery#1732 Closes gh-1736
Originally reported by pferreir at: http://bugs.jquery.com/ticket/10495
While trying to inject the Facebook "like button" JS in a page in execution time, I got some funny behavior:
fails (same with the equivalent before() call).
While
works just ok.
I tried different combinations of native/jQuery elements and they all fail. This happens at least since 1.6.1.
Issue reported for jQuery git