Side navigation
#4684 closed bug (patchwelcome)
Opened May 21, 2009 07:44PM UTC
Closed April 01, 2011 12:44AM UTC
Live events don't work in Opera when using XHTML and html()
| Reported by: | alex_sh | Owned by: | brandon |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | event | Version: | 1.3.2 |
| Keywords: | live event opera xhtml | Cc: | miketaylr@gmail.com |
| Blocked by: | Blocking: |
Description
Live events don't seem to work in Opera (tested with 9.64, Linux) when the new content is loaded via innerHTML (or jquery's html()), AND the document is XHTML (served via application/xml+xhtml, or opened locally with .xhtml extension).
Everything seems to work in Firefox 3.
I'm attaching two test cases (one xhtml, one html). A click event handler is attached via live() on the second button, while the first button replaces the second button with the dynamically created one. The click event is still executed in FF (both html and xhtml) and Opera with html version, but not in Opera with xhtml version.
Attachments (1)
Change History (10)
Changed June 24, 2009 03:18AM UTC by comment:1
Changed June 24, 2009 03:46AM UTC by comment:2
oh and btw, it works in the html version because tagnames in html are case-insensitive so the sizzle code converts every tagname to uppercase(only for XML documents).
Try with..
$('#contents_div>input').length
$('#contents_div>INPUT').length
Changed June 24, 2009 08:50AM UTC by comment:3
Well, it doesn't pose a problem in IE because IE doesn't support XHTML.
Writing $('#contents_div>INPUT') fixes the problem in Opera, but breaks FF (and possibly Webkit).
So, I guess this problem can be dealt with in two ways:
1. Make a workaround in jquery so that it produces the expected results in a cross-browser way. I think this is what it was mainly created for...
2. Report a bug to Opera software and hope that they fix it.
Should I file a bug report to Opera's bug tracker?
Changed June 24, 2009 03:34PM UTC by comment:4
I don't think this is a bug in opera because opera is just copying IE's behaviour for compatibility with IE-only sites. Perhaps the workaround mentioned on http://dev.fckeditor.net/ticket/1955#comment:2 by hallvord can be used in jQuery..
Changed June 24, 2009 04:16PM UTC by comment:5
Copying IE's behaviour in XHTML mode doesn't make sense since IE doesn't have XHTML mode at all. Opera should import the elements as they are, not changing their case at all.
The workaround you mention applies to reading from innerHTML, not writing to it.
Just to be clear - the problem is apparent when using the following code:
div.innerHTML = '<input type="button" value="New button" />'; alert(div.firstChild.tagName); // shows uppercase in XHTML instead of lowercase as in the original
Changed June 24, 2009 04:46PM UTC by comment:6
Ah yes, you are right. Opera shouldn't copy the behaviour in XHTML mode and this should get filed in Opera's bug tracker.
Changed June 24, 2009 05:06PM UTC by comment:7
I filed a bug report to Opera's bug tracker.
A portable solution is still needed until they fix it (if they fix it at all).
Changed August 15, 2010 12:04AM UTC by comment:8
Bug is still present in Opera 10.60 AFAICT by the test case.
Changed October 25, 2010 06:43AM UTC by comment:9
| cc: | → miketaylr@gmail.com |
|---|---|
| milestone: | 1.4 → 1.5 |
| priority: | major → low |
| status: | new → open |
Marking as valid and adding our Opera contact to the cc.
Changed April 01, 2011 12:44AM UTC by comment:10
| resolution: | → patchwelcome |
|---|---|
| status: | open → closed |
I will close this patchwelcome but most likely it will need to be fixed by Opera.
This happens because opera (like IE) converts tagnames to uppercase when using innerHTML so the selector '#contents > input' no longer matches. You can test it by simply running $('#contents_div>input').is('#contents_div>input') and $('#contents_div>input').is('#contents_div>INPUT') on the testcase before and after 'loading new contents' with .html().