arguments...callee...caller...

Originally posted May 3 2010

Recently I spent some time looking at generating a stack trace in JavaScript for the purpose of error reporting. There are plenty of existing projects out there that solve this problem, so I wouldn't recommend rolling your own.

As a result of this I came across some odd behavior in JavaScript. The code I was working with takes advantage of the special "arguments" variable (the "array" of arguments passed to the current function), which has a special "callee" property (the function that was called), which also has a special "caller" property (the function that called this function). You can probably see how this would be tempting if you're trying to construct a stack trace. Unfortunately, this information is attached to the function object rather than some sort of "function invocation" object. There are at least two cases where this makes constructing an accurate stack trace impossible.

1. Function recursively calls itself.
   
   
   • Since the caller property is attached to the function itself there is no way of knowing (through this information alone) how many times the function was called.
2. Function A calls function B, which then calls function A...
   
   
   • Even if there are terminating condition, the code that attempts to reconstruct the stack trace (using "callee" and "caller") will not terminate. There is a good description of this behavior here.

I was primarily interested in scenario 2, since this can cause errors. To get around this you can detect that you have already encountered a given function and simply stop. Of course this means that you lose any information that follows, but at least you won't hang the browser.

Conclusion: always check MDC :)

http://eriwen.com/javascript/stacktrace-update/

http://helephant.com/2007/05/diy-javascript-stack-trace/

http://bytes.com/topic/javascript/answers/470251-recursive-functions-arguments-callee-caller

http://msdn.microsoft.com/en-us/library/7t96kt3h

https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Objects/Function/caller

Web Service Syntax Error???

Originally posted April 7 2010

Ok, I'll start this post off with some background. A couple of years ago I wrote a SOAP web service that manages printing for multiple users through a web application. Sounds familiar, right? Anyway, the client that interacts with the web service uses the Microsoft AJAX JavaScript framework (version 1). The web service is hosted on a different server and domain. However, since this is an internal application with a small number of users they were content to enable cross-domain data access and be done with it.

A few weeks ago one of my coworkers was revisiting the client portion, which just happened to be upgraded to the beta version of the AJAX JavaScript framework. He started to see a syntax error, which I determined was occurring when handling the web service response. I knew that the client framework supported JSONP in some form, and I also noticed an interesting "jsonp" query string argument in the web service call. Believe it or not, the client was trying to use JSONP, even though the web service response was XML! This obviously would result in a syntax error when trying to deserialize.

After looking over the JavaScript code I determined that the WebServiceProxy was using JSONP if either the protocol or host of the request was different than the current page. I now know in hindsight that the documentation (at least in code) of WebServiceProxy.invoke clearly states this. Luckily, the "enableJsonp" parameter can be set to false to override this behavior.

So, the bottom line is: if you're accessing a web service across domains and you don't want to use JSONP, you have to set the "enableJsonp" argument to false. Here's the method signature and documentation...

WebServiceProxy.invoke(servicePath, methodName, useGet, params, onSuccess, onFailure, userContext, timeout, enableJsonp, jsonpCallbackParameter) {

/// <summary locid="M:J#Sys.Net.WebServiceProxy.invoke"></summary>

/// <param name="servicePath" type="String">Path to the webservice</param>

/// <param name="methodName" type="String" mayBeNull="true" optional="true">Method to invoke</param>

/// <param name="useGet" type="Boolean" optional="true" mayBeNull="true">Controls whether requests use HttpGet</param>

/// <param name="params" mayBeNull="true" optional="true">Method args.</param>

/// <param name="onSuccess" type="Function" mayBeNull="true" optional="true">Success callback</param>

/// <param name="onFailure" type="Function" mayBeNull="true" optional="true">Failure callback</param>

/// <param name="userContext" mayBeNull="true" optional="true">Success callback</param>

/// <param name="timeout" type="Number" optional="true" mayBeNull="true">Timeout in milliseconds</param>

/// <param name="enableJsonp" type="Boolean" optional="true" mayBeNull="true">Whether to use JSONP if the servicePath is for a different domain (default is true).</param>

/// <param name="jsonpCallbackParameter" type="String" optional="true" mayBeNull="true">The name of the callback parameter for JSONP request (default is callback).</param>

/// <returns type="Sys.Net.WebRequest" mayBeNull="true">Returns the request that was sent (null for JSONP requests).</returns>

MS AJAX and JSON Date Serialization

I'm making heavy use of Microsoft AJAX right now at work.  No, not the webforms controls, the JavaScript library.  That' s a little better, right?

Anyway, one of the nice little features in MS AJAX is the ability to invoke a web service, passing in some arbitrary JavaScript object(s), and it just works!  Well, mostly of the time anyway.  Today I found out that you have to be careful with dates.  When I called a web service in this manner, and the object was a Date or contained a Date, the deserialized DateTime object on the server was off by several hours.

At this point you're probably thinking, "I know what the problem is, you idiot!  It's local time!"  Hopefully you're more polite than that, but you would be right, of course.  Since JSON doesn't account for dates, we're forced to improvise.  Check out this link for a discussion of the JSON date format that the AJAX team decided on using.  You'll notice that he mentions several time that the string format represents a UTC date & time.  In my own defense, I simply provided a Date object and the rest was supposed to be magic (as we developers are so fond of saying).  After all, the Date object does include time zone information.  Unfortunately, the serialization code doesn't take that into account.

if (Date.isInstanceOfType(object)) {
     stringBuilder.append('"\\/Date(').
          append(object.getTime()).
          append(')\\/"');
     break;
}

Since the date was going to be converted to a string anyway I went ahead and did the conversion ahead of time.  Something like this...

var offset = obj.getTimezoneOffset() * 100 / 60;
var offsetText = offset >= 1000 ? offset.toPrecision(4) : "0" +
     offset.toPrecision(3);
return "/Date(" + (+obj).toString() + "-" + offsetText + ")/";

There are, of course, other ways to do this.  You could convert the date to a UTC date and let the serialization code do its thing.  This was my first solution, but I scrapped it in favor of the code above since it's more consistent with how the dates were formatted when sent from the server.  You could also parse out the offset from the date string with a regex, but that just didn't feel right.

Moral of the story:  either make sure your dates are UTC or serialize with the offset yourself.  I could think of cases where both would be inconvenient or impractical.  Hopefully you don't have to face that problem.

Tiny MCE Spellchecker Gotcha

In hindsight this should have been a lot easier...

If you're not familiar with tinymce you should go check it out.  Its a solid rich text editor for the web, which can be easily initialized and manipulated via JavaScript.  And best of all, its free!

Today I ran into a problem with the spell checking feature.  I'll go ahead and state up front:  this was NOT a problem with tinymce.  This was my own doing.  It seemed that, although the spell checker was able to report misspellings in the editor, when you clicked on a misspelled word the highlighting would disappear and no context menu was shown.  Strange...

First off, tinymce's source code can be downloaded from their site (see "Deveopment package"), which made debugging really easy.  I noticed while inspecting the page using firebug that when I triggered spell checking the misspelled word(s) in the editor were wrapped in a span with a special class name.  I tracked down the spot in the code where the text was wrapped happened, and more importantly unwrapped, and then set breakpoints so that I could intercept when this was happening.  I found that it was ultimately being called from a "mousedown" event, which was in turn creating a new undo operation in the editor and firing the editor's custom "change" event.

This took me back a few month to when I was integrating the editor into the website.  We basically use the editor to replace text areas on the page, which I gather is the norm.  Believe it or not, tinymce is kind enough to keep the original text area up to date as you make changes.  Unfortunately it doesn't seem to fire the native browser events that we needed to detect that these changes were occurring.  The editor has its own events, some which mimic native browser events.

One in particular that I was interested in was the "onChange" event.  The documentation states that the event is raised "when contents inside the editor gets changed."  If you look at the event handler arguments (Parameters) you'll see that it makes mention of "undo levels" and "undo managers".  As I understand it, the event actually fires when an "undo level" is added, some atomic action that can be reverted.  This explains why changes were being picked up at seemingly arbitrary times while editing the text.

Anyway, what does any of this have to do with the spell checking results disappearing?  Well, it turns out there were a couple of factors at work here.  The first I have already hinted at.  We were watching for "change" events on the editor and reacting accordingly.  These change events were also firing when you click inside of the editor, which is something that you would obviously do if you were trying to fix a typo to get rid of that nasty red underlining.  I presume this is because when the user has clicked, the text that they have typed can be viewed as an atomic action.  This can be slightly confusing if you don't know what to expect, but it does make some sense in that it follows Microsoft Word behavior (a worthy goal for a rich text editor).

At any rate, the second factor was even more tricky.  The behavior that depends on knowing when the editor changes  (the reason we're subscribing to the onChange event in the first place) also has to know what the current value is.  It is essentially a property change eventing mechanism.  This is all well and good, except that I was getting the editor's value through the editor object's getContent method, without so much as skimming the documentation for it (it seemed pretty straightforward).  The documentation states that the function will "cleanup the content before it gets returned using the different cleanup rules options."

If you think about it for a minute, you can see why this is a problem.  The editor's content is essentially going to be the html that is displayed, right?  So, if the function is going to return the editor's content, then it seems reasonable for it to "cleanup the content" first.  And what would cleaning up the content involve?  That's right!  It removes the html that wraps the text to signify that a word is misspelled.  After all, we wouldn't want to store that in the database.

So at this point I've determined what the problem is.  Luckily, it doesn't appear that I need to call the getContent method after all.  The original text area's value is updated anyway, so I just read the value directly from the text area. Problem solved!  Now I can go home...

Add JavaScript to a PDF Document with iTextSharp

Originally posted June 8 2010

As you might have guessed from the title, this post is of the “get it done” variety.  So, the code may be a little rough.  Its the sort of code that works, but isn’t fully understood (by me at least).  I wasn’t able to find a clear example on the net, so I pieced together examples and guesses based on reading the code and interpreting method and class names.

Why guess?  Well, iTextSharp is a pretty robust open source project which is useful for creating and manipulating PDF documents.  The problem is, it doesn’t seem to have any useful documentation online.  It is open source, so you can read the code all day.  Also, there are some tutorials that you can download from the files page (in the examples folder).

The goal was to have a PDF document print automatically from a web page.  I decided to pass on coming up with a cross-browser (read: works in IE) method for automatically printing the document on the client, and instead decided to insert JavaScript into the generated PDF document that would cause it to print when opened.  This is what I came up with.

PdfReader reader = new PdfReader(inputStreamOrFile);

int pageCount = reader.NumberOfPages;

Rectangle pageSize = reader.GetPageSize(1);

// Setup writer

PdfDocument document = new PdfDocument(pageSize);

PdfWriter writer = PdfWriter.GetInstance(document, outputStreamOrFile);

document.Open();

// Copy each page

PdfContentByte content = writer.DirectContent;

for (int i = 0; i < pageCount; i++)

{

document.NewPage();

PdfImportedPage page = writer.GetImportedPage(reader, i + 1); // page numbers are one-based

content.AddTemplate(page, 0, 0); // x and y correspond to position on the page?

}

// Insert JavaScript to print the document after a fraction of a second (allow time to become visible).

string jsText = "var res = app.setTimeOut('var pp = this.getPrintParams();pp.interactive = pp.constants.interactionLevel.full;this.print(pp);', 200);";

//string jsTextNoWait = "var pp = this.getPrintParams();pp.interactive = pp.constants.interactionLevel.full;this.print(pp);";

PdfAction js = PdfAction.JavaScript(jsText, writer);

writer.AddJavaScript(js);

document.Close()

As for the JavaScript, the call to setTimeOut is there so that the PDF is rendered before the print dialog is shown.  Otherwise, the users will see the print dialog and a blank page, which may be confusing.  If the PDF is not visible anyway (as in my case) then you don’t really need the timeout.  The actual printing is based on the documentation of Acrobat JavaScript from Adobe’s website.  In this example, the iteration level is set to “full”, meaning that the user will get the print dialog and progress feedback.  You can also use “automatic” (no dialog, includes progress) and “silent” (no dialog or progress).

PDF Embed Weirdness

Originally posted April 5 2010

The other day I was working on a web page where the user does some stuff and then as the result a nice, shiny PDF is embedded in the page. I noticed that in Internet Explorer (I was using IE8) the embedded region showed up as a blank rectangle with a little icon in the upper left-hand corner. Weird…

One of my co-workers suggested that I try embedding a static PDF file. In my case the source URL was an aspx page that dynamically renders the PDF. But that can’t possibly matter, right? I mean, as long as the content type is correct and the file is intact. I guess it does.

I won’t bore you with the details, but I determined through trial and error that the following conditions had to be met for the embedded PDF to display in IE8:

1) The “type” attribute must be specified as “application/pdf”, regardless of the fact that the external resource has the correct content type header. Because of my own ignorance I freely accept that there is probably a good reason for this. Besides, its good practice anyway – especially in my case (“what does this Page.aspx render as???”).

2) The URL must include “pdf” or “.pdf” (not sure if the “.” is necessary), even if on the query string! Really? I didn’t believe it myself, but I tested a gratuitous number of times and eventually disbelief gave way to sheer exhaustion.

3) Embed tag must be injected into the page with all attribute values at once (using jQuery) rather than injecting the tag and then setting attribute values (like type and src). This may be a jQuery issue, but its worth mentioning anyway.

So, the moral of the story is…

If it doesn’t work then first reduce the problem to its simplest form.