Revise workflow for drawURL to support ajax

[cburgmer]

Currently JavaScript is executed in the baseURL context of the page running rasterizeHTML, and not in the original baseURL, which will fail AJAX operations like lazy loading.

We should find out whether we can revise the current workflow and instead load the original URL in an iframe before inlining all resources. See #118 and #73.

[cburgmer]

Currently the 3 API methods use the same code in the last steps when handling the drawing. But that imposes the limitations of drawDocument() on the other two methods, and for drawURL() that means losing the original baseURL context.

Currently drawURL() is processing the call via loadDocument() before delegating to drawDocument() and drawHTML() is calling parseHTML() before doing the same.

Then the following happens:

• inlineReferences()
• executeJavascript()
• calculateDocumentContentSize()

in that order and while doing some additional, minor work.

Idea:

• loadDocument() + executeJavascript() should be merged and handled in one step for drawURL(). Both can happen in an iframe which run the JS code in the natural context. Open question: can the iframe loading fully substitute the current process done via XHR?
• parseHTML() + executeJavascript() can be equally merged, here we just construct the iframe's document ourselves.

Finally we can try tackling #80.

[cburgmer]

So, the reason I first gave up on trying to load a URL via iframe directly is the missing support for an onerror handler (while onload exists). While XHR can read status codes and correctly test same-origin access, this is difficult/impossible with an iframe.

Solutions:

• Ignore part of the problem (e.g. for a 404 just do the screenshot), find a clever work around for the rest (try accessing currentDocument, handle exception).
• Do a test-flight first, send a HEAD request via XHR and if successful, load again via iframe. Consistency is clearly an issue here.
• ...?