Bug Tracker

Opened 13 years ago

Closed 12 years ago

Last modified 11 years ago

#5876 closed bug (worksforme)

domManip caching doesn't evaluate scripts

Reported by: molily Owned by:
Priority: high Milestone:
Component: manipulation Version: 1.4.4
Keywords: dommanip cache Cc:
Blocked by: Blocking: #6779

Description

buildFragment() uses jQuery.clean() to extract the JS code of <script> elements. If it uses the cached DOM Fragment, clean() isn't called. In this case, the 'scripts' array remains empty so that evalScript() isn't called any longer.

Test case:

<p><a href="" id="start">call html()</a></p>

<div id="output"></div>

<script> $(function ($) {

$('#start').click(function (e) {

$('#output').html("<script> alert('should be executed'); <\/script>"); e.preventDefault();

});

}); </script>

This works as expected for the first and second click, but the third time the cache kicks in and the embedded script isn't executed.

This used to work in jQuery 1.3. I've encountered this bug in an Ajax environment using .load(). If the Ajax response is the same three times in a row, the embedded scripts weren't executed.

Change History (8)

comment:1 Changed 13 years ago by dmethvin

Component: unfiledmanipulation

comment:2 Changed 13 years ago by snover

#5818 is a duplicate of this ticket.

comment:3 Changed 13 years ago by snover

Blocking: 6779 added

(In #6779) Beyond just not testing for strings with no HTML, I suggested to only cache strings where the first character is a <.

comment:4 Changed 13 years ago by snover

Milestone: 1.4.11.5
Priority: majorhigh
Status: newopen
Version: 1.41.4.4

comment:5 Changed 13 years ago by snover

Keywords: dommanip cache added

comment:6 Changed 12 years ago by jitter

test case I can't reproduce this with 1.4.4 . snover could you reproduce this 3 weeks ago?

comment:7 Changed 12 years ago by molily

Apparently this was fixed in 1.4.2 because this version introduced more checks if a string is cacheable as a DOM fragment. Since 1.4.2, strings that match

rnocache = /<script|<object|<embed|<option|<style/i

are not cached.

This means the script execution problem I had reported does not occur an longer because HTML strings with script elements aren't cached into DOM fragments any more.

comment:8 Changed 12 years ago by john

Resolution: worksforme
Status: openclosed
Note: See TracTickets for help on using tickets.