HTML5, CSS3, jQuery, JSON, Responsive Design...

Horrendous Domino Ajax bug and world’s most useless technote (Updated)

Michael Brown   November 17 2012 07:30:00 AM
Update 5/5/2013
I recently updated my Domino server to Domino 9, and the bug that I described below appears to be fixed.  Certainly, it is not triggered in my Web NAB picker.  If you click on the live demo there, you'll see that I've modified the second name in the list to contain an exclamation mark.


This afternoon I was writing some jQuery/JavaScript to return JSON data from a Domino view using the "?ReadViewEntries&OutputFormat=JSON" syntax.  This is something that I have done many times in the past without problem.  But I was mostly using Domino 7 servers then...

This time, the server was 8.5.3 and the jQuery.ajax() call was failing.  After a while scouring through Firebug, I spotted a JSON parsing error about not properly escaping a backslash character.  Except, I knew that there were no backslash characters in the view's data.  But there it was in the returned JSON data: a backslash character in front of an exclamation mark... in front of every exclamation mark!

A bit of Googling has turned up the following technote, which has to be read to be believed:

http://www.ibm.com/support/docview.wss?uid=swg1LO63774

It's a bug in the readviewentries&outputformat=json syntax in Domino 8.5.2/8.5.3.

The character "!" appears as "\!" in the JSON response but should be "!".


No shit?

No explanation given as to how this has happened.  Let alone any apology for screwing over one the best features that the product has had in years.  Not to worry though, they do give us a "Local fix":

Do not use character "!" in queried data.


Where would be all be without IBM Support?  It sure was a weight off my mind I can tell you.  All I have to do is tell all my users to keep their fingers away from that pesky exclamation mark key and all will be well.  Maybe I could have the desktop guys go around the building and physically pry it off the keyboards?  They'll still have their right-hand number pad if they need to use a "1" ever (although we can always try to ween them off that too, I guess).

The technote is marked:

This APAR is closed as FIN. We have deferred the fix to a future release.


Can anybody translate "closed as FIN" into English?  And what "future release" is this filthy, stinking, howler of a regression bug actually going to be fixed in?  For that matter, why the f*** hasn't it been fixed before now?

Note: a further Google turned up a posting on the Domino 8 forum claiming that the greater than symbol (>) is similarly affected by the Domino Development Team's predilection for sprinkling unwanted backslashes upon us all.


Update 17/11/2012 - Proposed Workaround

I am now implementing the jQuery/JavaScript workaround below.  I need to test it further, especially in IE, but it's looking good so far.

In Firebug, I saw that when a JSON.parse error is triggered in the $.ajax() call, jQuery passes in a second parameter to the error function, and that second parameter's value is set to "parsererror".  Also, the first parameter is an object, which has a .responseText attribute whose value is the source text of the JSON data that was returned. (The jQuery documentation confirms these parameters.)

Putting all that together, I am able to trap the "parsererror" within the $.ajax() call's error function.  I then run a couple of chained regular expressions to remove the extraneous backslashes from the .responseText data source.  I then parse the scrubbed JSON string data manually before passing it to my success function.

Here's the code:
$.ajax(
        {
                url: '/mydb.nsf/myview?readviewentries&outputformat=json',
                dataType: 'json',
                success: function(data) {                       {
                        mySuccessFunction(data);
                },
                error: function(arg1, arg2) {
                        if(arg2 ==="parsererror") {
                                var parseFix = true;
                                 var parsedJSON;
                                try {
                                        var jsonSource = arg1.responseText;
                                        jsonSource = jsonSource.replace(/\\\!/g, "!").replace(/\\\>/g, ">");
                                         parsedJSON = $.parseJSON(jsonSource);
                                }
                                catch(e) {
                                        parseFix = false;
                                        alert("Error: " + e);                
                                }
                                if(parseFix) {
                                        mySuccessFunction(parsedJSON);
                                }
                        }
                        else {
                                alert("Error: " + arg1);
                        }
                }
        }
);


Of course, it's still a huge pain the arse to add this code to every $.ajax() call, but the beauty of doing it this way is that once the bug is finally fixed (see comments), the fix code should never be triggered again.

 
Comments

1Simon O’Doherty  11/15/2012 7:37:53 AM  Horrendous Domino Ajax bug and world’s most useless technote

FIN = Fixed in Next release. By Next it means a later release, or scheduled to be fixed in a later release. It is not a great description, but it is a keyword as part of the automated system.

I checked the status of CJON8LMQCD and it is marked as fixed in Notes Social 9.0. I'd recommend to get the beta if you can and double check it.

If this is a serious impact I'd recommend to open a PMR.

2Mike Brown  11/15/2012 4:00:12 PM  Horrendous Domino Ajax bug and world’s most useless technote

Thanks for the info, Simon.

FYI, I did check the fixlist db and other sources before posting yesterday. Where did you look to get your info?

3Nathan T. Freeman  11/15/2012 11:44:45 PM  Horrendous Domino Ajax bug and world’s most useless technote

@Simon, I'm going to go out on a limb here and say that "FIN" is a terrible choice of abbreviation when it means "end" in both French and Spanish. { Link }

Any student of romance languages would be tempted to believe that such a status means "we're through with this report."

4Simon O’Doherty  11/16/2012 2:40:51 AM  Horrendous Domino Ajax bug and world’s most useless technote

@Mike I work in IBM, so internally.

@Nathen I agree, I hate some of the TLA's used. :)

5Mike Brown  11/16/2012 4:08:09 AM  Horrendous Domino Ajax bug and world’s most useless technote

@Simon,

Then double thanks for sharing that info!

About