Response title
This is preview!
Move this topic
Hi,
My first question is:
Has there been a fix in the meantime?
Thanks in advance!
jQuery Ajaxify Plugin: https://4nf.org/
1
Replies(45)
They closed it, and closed your ticket. Ask the devs.
JΛ̊KE
Leave a comment on jakecigar's reply
Thanks Jake, much appreciated!
I suppose I'll post another comment at the bottom of the issue, even though it's closed, if that's not too intrusive...
My second question is:
If nothing can be done about the issue at a jQuery level, which I presume, how does the fix proposed, using:
work?
(That would be a completely satisfactory workaround)
Leave a comment on arvgta's reply
htmlPrefilter Is a jQuery sanctioned kludge. If you are using XHTML strings it could help. Try it.
JΛ̊KE
Leave a comment on jakecigar's reply
Hi Jake, thanks once more!
I have just performed the following measures:
Seeded the following code in the main initialisation of the Ajaxify code:
- $.log("htmlPrefilter : " + $.htmlPrefilter);
That correctly returns the default function body of htmlPrefilter as expected (I am using jQuery version 1.12.4).
(Let's not bother, what the default function is)
I then overrode the default function body as follows in the same main initialisation, just above the previous line:
- $.htmlPrefilter = function( html ) { return html; }
The above $.log() message shows the new function correctly.
Finally I enabled some code known to trigger the error in a social media plugin (function csbwfsGetCookie):
- ...for(var i=0; i<ca.length; i++) {...
The above code is within an inline script.
Unfortunately, the result is the same... (I get a hard error)
What's happening when loading the target page, via Ajax and then into the jQuery selector, is that the "less than sign" within the for loop is being interpreted as an opening tag by jQuery.
If I place a space after the "less than sign" everything works fine (!)
Therefore, I'm unsure whether, this all has anything to do with the original bug of this thread.
I've left the erroneous logic alive at the moment on 4nf.org. (have a look at the console when switching pages)
I would like to re-iterate a bounty of €100, payable via PayPal for any decisive help, leading to the resolution of the bug...
------------------------------
Additional information:
The same bug happens with the inline script of the Emoji logic, enabled by default in Wordpress... So the bug pertains to all Wordpress users unless they disable the default logic
See also: Thread at GitHub
------------------------------
EDIT: I think, I know what it is:
The Ajaxify plugin escapes scripts, whether external or inline to
- <ajy-script>...</ajy-script>
...before dumping the whole page into the jQuery selector...
....so the jQuery parser has no fair chance to treat inline script contents as usual...
The most elegant solution would be, not to escape script tags at all. Do you think that that is viable?
At the moment, the plugin is escaping:
- html
- head
- body
- link and
- script
tags, so that the jQuery selector can "digest" the target page
I can see two follow-up questions:
- Can the jQuery parser handle script tags at the top level (i.e. without parent tags)?
- How can one prevent the scripts from being fired?
Leave a comment on arvgta's reply
- <ajy-script>...</ajy-script>
is a crazy tag. You should probably use
- <script type="text/ajy">…</script>
Which should have the ability to have a less than sign that does not confuse the browser.
If that doesn’t work, you will have to encode as <.
JΛ̊KE
Leave a comment on jakecigar's reply
An extremely simple page…
- <script type="text/ajy"> I<a </script>
- <ajy-script> I<a </ajy-script>
Does not parse the ajy-script correctly, but parses the <script type="text/ajy"> properly.
JΛ̊KE
Leave a comment on jakecigar's reply
If you do your Ajax as text. Then encode it yourself, so that any < inside a <ajy-script> is recoded to "<" it would parse as well.
JΛ̊KE
Leave a comment on jakecigar's reply
Sorry for the misunderstanding.
The script tags are escaped to:
- <div class="ajy-script">...</div>
Leave a comment on arvgta's reply
Makes no difference!
- <div class="ajy-script"> I<a </div>
won’t parse correctly. By ANY browser!
JΛ̊KE
Only a <script …> tag can have a stray < followed by a letter in it.
JΛ̊KE
Leave a comment on jakecigar's reply
Thanks Jake!
It's only an intermediate representation of the target page in a cache.
I then fetch the scripts in a second pass and re-assemble them with injection into the DOM - a bit like a single-page application.
So my question is:
What happens if I don't escape them in the first pass?
- Will the jQuery parser be able to "digest" them?
- Can I prevent them from being fired?
Leave a comment on arvgta's reply
At some point convert the < to < before it turns into DOM nodes.
It has nothing to do with jQuery. It’s an HTML thing. HTML4 was worse! But HTML5 can handle <a inside a <script>. No other tag, I know of, can do that.
You could get the file using $.ajax with type "text", then replace < by < inside your "scripts". Then append it to the DOM. When you get it back (as text) it will be a <.
JΛ̊KE
Leave a comment on jakecigar's reply
I just remembered that there is an obscure jQuery method to use $.ajax but pre or post process the result.
jQuery.ajaxTransport() | jQuery API Documentation has a converters parameter that could help clean up the code.
JΛ̊KE
Leave a comment on jakecigar's reply
Great stuff!
Sounds like a possible solution - escaping the opening tabs with < within the "script" tags.
I will try making a coarse sort of feasibility study with for loops, iterating through the "script" tags and see, whether that changes anything...
Leave a comment on arvgta's reply
It’s the second best. The best is using
- <script type="ajy-script">...</script >
JΛ̊KE
Leave a comment on jakecigar's reply
ajy Is a tiny demo that replaces < by < I didn’t use ajaxTransport.
The Ajax’d file is just
- <div class="ajy-script"> I<a </div>
- <div class="ajy-script"> J<a </div>
- <div class="ajy-script"> k<1 </div>
JΛ̊KE
Leave a comment on jakecigar's reply
Thanks for the overwhelming support!
Is it still your opinion, that the solution with:
- <script type="ajy-script">...</script >
is the best?
I reckon, too, that that is even more elegant than replacing the opening tag with <
I would just need the RegEx, that replaces JavaScript "<script>" tags with the above along with the reciprocal jQuery selector to fetch them back in...
I think that would amount to even less code than your kindly supplied demo...
Leave a comment on arvgta's reply
The key word is elegant. Everything else is a kluge.
Can’t you keep them in the DOM as <script type="ajy">? All the HTML4 compatible templating libraries use them!
JΛ̊KE
Leave a comment on jakecigar's reply
Yes, exactly - a coarse job could even introduce some other new bugs or side-effects...
I can escape the JavaScript "script" tags with those of
- type="ajy"
in a first step - sure.
(Unfortunately, I'm not good at RegExs)
I'd have to fetch them back in with jQuery before injecting them back into the DOM
Fetch them with jQuery Ajax or the new Fetch API.
With a <script> tag you don’t have to use a regex at all. You can select $("[type=ajy]") A <script type="ajy"> works just like a <div>, except it is hidden by default.
JΛ̊KE
Leave a comment on arvgta's reply
Thanks Jake!
I have to escape the JavaScript "script" tags at a textual level first, before dumping them into the jQuery selector.
The logic is simple in the form of pseudo code:
- For all "script" tags: If no type specified or type = "text/javascipt" -> new type = "ajy"
The code you supplied (or something very similar):
- $("[type=ajy]")
...is good for re-fetching them
Leave a comment on arvgta's reply
"text/javascript" is the default. People no longer specify it. If type is specified and is not one of the proper ECMA script names ("text/javascript" "application/ecmascript" … ) it is not executed.
JΛ̊KE
Leave a comment on jakecigar's reply
Thanks Jake!
If the type is different to <none> or "text/javascript", I would like to keep it.
Otherwise, I would like to set the type to "ajy".
What's the RegEx for doing that?
(just checked the markup on my site - some e.g. Wordpress plugins do still specify "text/javascript". I have to have support for that in any case)
So if you could supply the RegEx, I could start going ahead with the first tests...
Leave a comment on arvgta's reply
You ignore any script that is not type=ajy. You are overthinking this.
JΛ̊KE
Leave a comment on jakecigar's reply
Formidable, Jake!
It's even simpler then - what's the RegEx for the following pseudo-code:
- For all "script" tags: If no type specified or type = "text/javascipt" -> new type = "ajy"
?
(not using jQuery but at a textual level)
Leave a comment on arvgta's reply
The HTML that you use Ajax to load may have lines like
If this isn’t making sense, post a minimal ajy file and I will make a tiny demo.
- <script> some javaScript </script>
- <div> some other stuff </div>
- <script type="ajy"> some ajy stuff </script>
Just insert it all into the DOM. The first script gets executed. They both stay in the DOM. You can access the second with
- $("[type=ajy]")
If this isn’t making sense, post a minimal ajy file and I will make a tiny demo.
D’accord?
JΛ̊KE
Leave a comment on jakecigar's reply
I hope you are not trying to "parse" HTML with RegExs!
You can't. Not properly.
That said, I've done it, but only with knowledge of the structure of the particular HTML.
Parsing non-nesting <script> tags with a regular expression is very simple. But since it doesn’t need to be done, there is no point in discussing how it is done.
JΛ̊KE
Leave a comment on watusiware's reply
"Parsing non-nesting <script> tags with a regular expression is very simple."
So long as it isn't commented-out.
Just the first edge case that comes to mind.
I wouldn't try to "parse" any HTML with a RegEx, unless it is HTML that I have control over. And, then, with an understanding of the limitations.
Not a problem when the <script> has a type and does not contain javaScript.
JΛ̊KE
Leave a comment on watusiware's reply
All you have to do is change
- <div class="ajy-script">…</div>
to
- <script type="ajy">...</script >
- $(".ajy-script")
to
- $("[type=ajy]")
All should work. No regexes are needed.
JΛ̊KE
Leave a comment on jakecigar's reply
My concern about regex's is more general. I read an implication that RegExs might be being used for more extensive HTML "parsing". RegExs wouldn't be my first tool for finding/replacing/modifying HTML elements.
And nobody is suggesting he use regular expressions.
JΛ̊KE
Leave a comment on watusiware's reply
"I would just need the RegEx...."
... would seem to imply that this is the approach presently used...
And a quick look at the code confirms that.
An example of one of the ways this fragile code will break: just add a space after any of the <s.
< html>
Legal HTML that will not work with this code.
- //Regexes for escaping fetched HTML of a whole page - best of Baluptons Ajaxify
- //Makes it possible to pre-fetch an entire page
- docType = /<\!DOCTYPE[^>]*>/i,
- tagso = /<(html|head|body|script|link)([\s\>])/gi,
- tagsc = /<\/(html|head|body|script|link)\>/gi,
- //Helper strings
- div12 = '<div class="ajy-$1"$2',
- linki = '<link rel="stylesheet" type="text/css" href="*" />',
- scri = '<script type="text/javascript" src="*" />',
- linkr = 'link[href*="!"]',
- scrr = 'script[src*="!"]';
Leave a comment on watusiware's reply
Hi Watusiware,
thanks for your feedback, too!
The approach of Ajaxify is somewhat pragmatic, but I would agree with Jake, that it is viable, as long as the tags escaped are at a top level / not nested. If that were not the case, one would indeed need an HTML parser, which would be way over the top...
Your example of < html> (with the space) is correct - that might cause unwanted effects and seems fragile - however:
- GIGO -> Garbage In, Garbage Out
- CMS usage -> a proper CMS will not generate such tags
- Responsibility of the user -> He has control over Ajaxify and the HTML at the same time
In practice, a potential Ajaxify user will quickly test the plugin against his existing site and not use it, if it falls over or causes any other unwanted effects.
Let's work toward the small improvement, that this thread is originally about:
- The issue about HTML-like tags within "script" tags
I would suggest, to integrate the improvement at 4nf.org. (Don't know, how long that will take and how difficult it will be)
Once the tweak is working, we can evaluate the result...
Leave a comment on arvgta's reply
Hi Jake,
yes and no - but I would like to pay you the bounty for your excellent support in here and in the past if you are "d'accord" ;)
Thanks! I assumed you spoke French, you wrote formidable, Which is rarely used in English.
Par conséquent, d’accord.
JΛ̊KE
Leave a comment on arvgta's reply
Hi Jake,
Obviously, this thread has it's deliverable in the sense that we found out, what the cause of the bug was and that it is not the jQuery parser's fault.
Having said that, I still don't have a productive fix for my bug.
It would be great, if we could keep this thread alive for that purpose...
Leave a comment on arvgta's reply
I am sure future generations of programmers will see this and they will learn not to put a greater than sign in html in anything other than a <script> tag.
JΛ̊KE
Leave a comment on jakecigar's reply
What do you mean by that?
You can’t put "<" as content ,especially if it is followed by. a letter in anything other than a <script> tag. They get corrupted by the browser.
People find the threads via search engines.
JΛ̊KE
Leave a comment on arvgta's reply
So you don't mean that cynically?
Not at all. When I have a problem I google first.
JΛ̊KE
Leave a comment on arvgta's reply
So did I, but I didn't find anything salient. Lot's of somewhat related threads at StackOverflow, but not a good match...
Leave a comment on arvgta's reply
I know how it is! I’ve found more wrong answers to wrong questions. But I keep on searching.
Sometimes, a question has never been asked! And that’s why we’re here.
JΛ̊KE
Leave a comment on jakecigar's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to arvgta's question
{"z7664639":[14737000007425271,14737000007425273,14737000007425275,14737000007425277],"z20833501":[14737000007425002,14737000007423019,14737000007424119,14737000007428089,14737000007428095,14737000007428101,14737000007428107,14737000007428111,14737000007428121,14737000007424123,14737000007424125,14737000007433001,14737000007433013,14737000007434001,14737000007434003,14737000007434005,14737000007435001],"z2950240":[14737000007425011,14737000007425055,14737000007428075,14737000007428081,14737000007428085,14737000007428091,14737000007428093,14737000007428097,14737000007428099,14737000007428103,14737000007428105,14737000007428109,14737000007428113,14737000007428159,14737000007428171,14737000007428189,14737000007428191,14737000007428197,14737000007428195,14737000007428203,14737000007433027,14737000007433029,14737000007433033,14737000007433035,14737000007433037]}