JBossDeveloper

I found that a similar fix worked with RichFaces 3.3.1.GA and IE10, except:

#1 is on line 1394, and I did this:

               oldnode.outerHTML = (Sarissa._SARISSA_IS_IE && typeof newnode.xml != "undefined") ? newnode.xml : new XMLSerializer().serializeToString(newnode);

#2 wasn't needed, Instead I commented out the log statement on line 2036

              //LOG.debug("Hidden JSF state fields: "+idsSpan);

Also, I was able to fix this without updating any jar files.   I copied the resource out of the jar, added it into my /js directory and referenced it with a <script> tag in my main XHTML view template.   Works fine.

Above mentioned fixes most of the issues in the IE9.

But rich:dragSupport still doesn't work. (As with the demo).

I can't find any mention of this anywhere else as well. Can this be fixed any JS library upgrade ?

In my app, RichFaces 3.3.3.Final calendar widget doesn't work at all in the latest FF, Chrome or IE.   So I downgraded to 3.3.1.GA, which still has the AJAX.js issues, but I've just patched that (not in the jar, in the page by referencing my own copy of the resource after JSF automatically includes the one from the jar).

My point is, drag/drop isn't the only thing that doesn't work in 3.3.3.Final.   I'm willing to fork it and build my own 3.3.4 with bugs fixed.   Unfortunately, it's still in SVN, so no nice fork / pull request capability.

Joshua,

Does 3.3.3.Final has fixes for AJAX? I was under the impression it didn't.

For overriding the JS, we copied it into our javascript directory and used apache mod_rewrite to override it.

#Rewrite Richfaces JS
RewriteCond %{REQUEST_URI} ^/(.*)/a4j/g/3_3_1.SP3/org/ajax4jsf/framework.pack.js(.*)$
RewriteRule ^(.*)/a4j/g/3_3_1.SP3/org/ajax4jsf/framework.pack.js(.*)  /my-web-app/javascript/richfaces/framework-richfaces-331-hrx-patch.js$2 [PT,QSA]

Still no joy though. It still breaks drag and drop. We use calendar from myfaces i think (coz we had other issues with richfaces calendar).

Note, after applying Josh's fixes, there are still some IE10 issues.

Specifically it's having trouble with window.document.importNode()

The problem is window.document.importNode() does not report itself as undefined in IE10 (haven't looked at IE9).

Instead, it is defined, but throws an "No such interface supported." exception.

A4J is specifically checking for "undefined", but not for the "No such interface supported" exception:

if((typeof(document.importNode) == "undefined") && Sarissa._SARISSA_IS_IE){
...
document.importNode = function(oNode, bChildren){
...
}
...
}

but in IE10, typeof(document.importNode) == "undefined" is false

So we need to update this logic.  I'm not sure if we can just update the check to Sarissa._SARISSA_IS_IE (without the undefined check), or what.

Alternately, could we get a more advanced importNode replacement from another library with better browser checking and drop that in?

Thoughts?

I'm also thinking of factoring out our own _importNode() method that could catch this exception and try something else.

Overriding window.document.importNode() seems like a bit of overkill for my taste since we're just going to be calling the method in that file anyways (why mess with everyone else's copy of importNode()?).

For me I'm specifically seeing this when trying to rerender a column.

updatePagePart() uses different logic when rerending for table type elements.

updatePagePart : function(id, isLast){
...
if(!window.opera && !A4J.AJAX.isWebkitBreakingAmps() && oldnode.outerHTML && !oldnode.tagName.match( /(tbody|thead|tfoot|tr|th|td)/i ) ){
...
} else {
...
var importednode = window.document.importNode(newnode, true)
}

A little bit of a vent here, but when putting in all this crazy browser support logic, it would be really helpful if stuff like

if(!window.opera && !A4J.AJAX.isWebkitBreakingAmps() && oldnode.outerHTML && !oldnode.tagName.match( /(tbody|thead|tfoot|tr|th|td)/i ) ){

was commented, or at least had a reference to a jira issue.

It's not at all obvious why this is branching on table tags here.

Apologies if this post sounds little frustrated, but this seems like we're being left to swing in the wind here a bit.

I would really like to submit a pull request for this.   I guess we'll have to make a fork with subversion and submit a patch.

Hi Folks,

A gentle reminder that we are no longer developing RichFaces 3, having moved on to RichFaces 4/5.  I understand migrating applications from JSF 1 / RichFaces 3 to JSF 2 / RichFaces 4 is non trivial, but if support for modern browsers is what you are after, then this is the way to go.  Please ask in the forum and file jira's as appropriate if you have trouble migrating to RichFaces 4.

As for svn/git, we migrated to git/github with RichFaces 4.  Unfortunately the massive amount of history and non-standard branch names in RichFaces < 4 made it problematic to migrate the entire history, so we only migrated the RichFaces 4 sources.  If you want to try this migration yourself - I'd recommend doing it only for the single RF 3.3.4.Final tag.

Fair enough.   We can patch it in our current version and use this as one more reason to upgrade to RF4 (JBoss AS 7, Seam 2.3, etc).