Side navigation
#6971 closed bug (wontfix)
Opened August 30, 2010 08:53PM UTC
Closed October 15, 2010 02:18AM UTC
Chrome optimization avoids load events
| Reported by: | vegetablebread | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | 1.4.3 |
| Component: | unfiled | Version: | 1.4.2 |
| Keywords: | webkit image load | Cc: | |
| Blocked by: | Blocking: |
Description
Google's chrome browser will not load a new image if the image's src attribute is set to the same value, although all other browsers will. Example:
$('#image_id').load(function(){alert('test');});
$('#image_id').attr('src',path);
$('#image_id').attr('src',path);
Attachments (0)
Change History (3)
Changed August 30, 2010 11:54PM UTC by comment:1
Changed September 23, 2010 06:08AM UTC by comment:2
| priority: | → undecided |
|---|
All WebKits act the same way here and do not fire any events if you are setting the src of an image to the same value that is already set. There was some work to try to normalize image load events cross-browser, but in these cases, the behaviour will end up being normalized to match WebKit behaviour.
Changed October 15, 2010 02:18AM UTC by comment:3
| keywords: | → webkit image load |
|---|---|
| priority: | undecided → low |
| resolution: | → wontfix |
| status: | new → closed |
Making a note to consider documenting this behavior in the API docs. As it would appear that the behavior listed would in any case be reverting to match Webkit's standard handling of the load events for the image src, it doesn't appear that there is much more we can do to resolve this particular ticket without breaking what Webkit expects to happen. Closing for now but I leave it open for another triage member to reopen if they feel otherwise.
Your particular example might actually abort the previous request and start a new one since it doesn't wait for the first load. If it does fail to fire on a cached request, I'm not sure there's anything we can do about it inside jQuery. We could document it in the .load() api page I suppose.