Side navigation
#14370 closed bug (patchwelcome)
Opened September 18, 2013 02:49PM UTC
Closed September 19, 2013 01:18PM UTC
Last modified February 02, 2014 07:29PM UTC
.html(data) incorrectly modifies some regular expressions resulting in global eval script errors
| Reported by: | dgtanner@gmail.com | Owned by: | gibson042 |
|---|---|---|---|
| Priority: | low | Milestone: | 1.11/2.1 |
| Component: | manipulation | Version: | 1.8.3 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Example of the problem (open up chrome console to view errors)
Example of the problem:
http://www.cs.utah.edu/~dgtanner/cre/bugexample.html
which uses ajax to call and load the page
http://www.cs.utah.edu/~dgtanner/cre/badpage.html
Working example of a workaround.
http://www.cs.utah.edu/~dgtanner/cre/workingexample.html
which uses ajax to call and load the page
http://www.cs.utah.edu/~dgtanner/cre/goodpage.html
the only difference is the regex change between badpage.html and goodpage.html
Attachments (0)
Change History (11)
Changed September 18, 2013 05:00PM UTC by comment:1
| owner: | → dgtanner@gmail.com |
|---|---|
| status: | new → pending |
Changed September 18, 2013 05:08PM UTC by comment:2
Replying to [comment:1 dmethvin]:
In general it's dicey to attempt to inject an entire page (including<html>,<body>, etc) into a<div>element. This behavior, which is out of the control of jQuery, is mentioned in the docs. Does the example break the same way when you inject a valid html fragment into the div? Does it fail the same way in all browsers? I didn't see a problem in Firefox.
This fails in Chrome, Firefox and Internet Explorer. (The ajax replace does succeed, but a javascript exception is thrown when jquery tries to evaluate the script) This breaks other scripts run on the page after the call.
Changed September 18, 2013 05:13PM UTC by comment:3
Sorry, I'll be more specific. Please create a test case that eliminates the extraneous <body> etc.
Changed September 18, 2013 06:10PM UTC by comment:4
Replying to [comment:3 dmethvin]:
Sorry, I'll be more specific. Please create a test case that eliminates the extraneous <body> etc.http://www.cs.utah.edu/~dgtanner/cre/bugexample2.html
loads the following page page via ajax.
http://www.cs.utah.edu/~dgtanner/cre/badpage2.html
<body><head> etc, have been removed as requested.
Changed September 18, 2013 07:30PM UTC by comment:5
){kind=link}
Changed September 18, 2013 07:33PM UTC by comment:6
If step through and look at the variables I notice that
.replace(/<br\\/>/g,"\\n\\t") is changed into something invalid like .replace(/<br/><t/>/g,"\\n\\t")
before being globally evaluated (see stack above).
Changed September 18, 2013 10:09PM UTC by comment:7
| component: | unfiled → manipulation |
|---|---|
| milestone: | None → 1.11/2.1 |
| owner: | dgtanner@gmail.com → gibson042 |
| priority: | undecided → low |
| status: | pending → assigned |
We use a very coarse regular expression to convert self-closing tags into open-close pairs before setting innerHTML for oldIE (#1549). Replacement happens regardless of context, be it inside a CDATA section, comment, textarea, or—as in your case—script. I'll look into a more sophisticated replacement scheme:
// no-innerHTML container ($1) or self-closing element that should close ($3-$7) rxhtmlTag = /(<!\\[CDATA\\[[\\w\\W]*?\\]\\]>|<!--[\\w\\W]*?--|<(script|textarea)[\\w\\W]*?>[\\w\\W]*?<\\/\\2)|(<)(?!area|br|col|embed|hr|img|input|link|meta|param)(([\\w:]+)[^>]*)(\\/)(>)/gi; // no-innerHTML container; "<"; element name and content; ">"; "<"; "/"; element name; ">" rxhtmlTagReplacement = "$1$3$4$7$3$6$5$7"; ... html = html.replace( rxhtmlTag, rxhtmlTagReplacement );
Note, however, that the file size increase may be too great to justify the changes. It is highly recommended that you take advantage of escaping to dodge our regex (e.g., /[<]foo\\/>/ or "<" + "bar").
Changed September 19, 2013 01:18PM UTC by comment:8
| resolution: | → patchwelcome |
|---|---|
| status: | assigned → closed |
As suspected, my implementation was just too big.
Changed October 19, 2013 02:28AM UTC by comment:10
| blocking: | → 14464 |
|---|
(In #14464) HTML5 throws in a monkey wrench, but in my opinion it's pointless to fix this without a more sophisticated regular expression, and I remain convinced that such an improvement does not offer enough value to justify its large size.
At most, I could see exposing pre-innerHTML replacement arguments as properties of jQuery for users to tweak if they want to accommodate such edge cases.
Changed February 02, 2014 07:29PM UTC by comment:11
#14329 is a duplicate of this ticket.
In general it's dicey to attempt to inject an entire page (including
<html>,<body>, etc) into a<div>element. This behavior, which is out of the control of jQuery, is mentioned in the docs.Does the example break the same way when you inject a valid html fragment into the div? Does it fail the same way in all browsers? I didn't see a problem in Firefox.