option to allow-scripts in testcase #66
Comments
|
Hey, if I understand correctly, you want to inject parameters into the test case HTML. You propose a solution by injecting the parameters via the URL. Correct me if I am wrong. This is an interesting suggestion, which I might need to ponder on for a bit longer. You are though already able to run JavaScript inside the rendered page. There is nothing you need to do for that to happen, it should just work. The sandboxing only happens at a later stage when the dimensions of the page are measured and is unrelated to the JS execution. You should see some JavaScript in csscritic's own UI test cases (https://github.com/cburgmer/csscritic/tree/master/test/ui). The way JS is executed inside rasterizehtml though, you won't have access to the page's URL. The reason being that in an earlier stage the HTML has already been loaded as source and all references inlined, and the document therefore detached from the original URL. Source here: https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/browser.js#L20 If you are interested in the details: You could just open the URL in an iframe, which would trigger JavaScript (btw. with your code above working), and afterwards extract the modified DOM, however in case you sneak in an URL that rasterizehtml cannot access due to same origin limitations, then there is no way ever to be notified via iframe.onload that the page could not be loaded (because of the security restrictions of the browser). In that case we could never notify the user that the content could not be loaded. Therefore the current solution: load the content via ajax first (fail properly on same origin limitations) and inject HTML into iframe. Back to your request: You could inject objects into the iframe though, and we are already doing it: https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/browser.js#L57. Does that help? I could in the future see rasterizehtml providing a way of injecting external things into the page (e.g. just like PhantomJS eventually supported communication between sandbox and outer context). |
|
First paragraph is correct. I get the following error in chrome: |
|
changing this line: to |
|
I'm not seeing script execution in firefox developer edition either |
|
Yes, the browser is warning about the script content in the sandboxed frame, and I'd like to shut off this warning, as it is not helpful. Can you look at https://github.com/cburgmer/csscritic/blob/master/test/ui/niceReporterFailingTestAccepted.html and say how your setup is different? Maybe the (repeated, because already used in the executeJavascript message) With preview I believe you mean the 'true DOM view' (looking for a better name)? This is actually just the same page but in an iframe. |
|
yes, by "preview" I mean the |
|
I'm probably being stupid but I don't really understand how that test works. I've only ever used the (That testcase passes in the jasmine specrunner on my machine in chrome) |
|
So I if I add a line here: I can get rasterizeHtmlOptions.baseUrl in the testcase's script and get it to write out the |
|
Yes, indeed. The resource inlining step has already executed by then. As I mentioned above, the limitations stems from the need of rasterizehtml to know when the iframe finished loading, and the browser not sharing this information if the URL is not from the 'same domain'. I'd love to find a proper solution for that issue, as this is a limitation I myself have been hitting for a while. In such a case the JavaScript execution would happen first, and only then the resources inlined. For the time being I don't see an easy solution for you, maybe shy away from injecting CSS for now? This feature request is still valid anyhow, though. |
|
Let me know if what I said makes sense. I'd be happy if you could prove otherwise, and find a solution to the problem of loading urls for any domain and correctly report errors for non-same-domain access. |
|
I got inclining the CSS to work by adding another call to I'm running csscritic on the same domain as my tests and css, using the If the cross domain tests can have csscritic js in them you could use a
|
|
|
I think it would be good to revisit why javascript execution happens after inlining. I once tried to reverse the two of them but got stuck somewhere a long the way. I don't fully remember why, possibly for a very valid reason. Once thing I definitely would like seeing tried: Can we just load any URL in an iframe and get load errors even if the URL is not under the same-domain? Current constraints are: we need to be notified once all resources are loaded (document.load and xhr finished) and receive JS execution errors for reporting. If we can manage to solve this, you have proper execution in the iframe, and no additional means would be necessary as far as I can tell. Porthole looks interesting, but AFAIK it needs the iframe to play along nicely? |
|
Re porthole. Yes would need the iframe/testcase to play along and run some
|
|
So I wouldn't give up yet on getting the iframe to properly load everything. I might try again some time soon. As to 'more complete' rendering. I've always envisioned CSS Critic as a unit testing solution. So if you are doing too much in your test, than that might go against the original design. I do agree though that there are use cases where the JS needs to do something, and where CSS Critic gets in the way. While there are quite often tweaks around that, I'd like to solve this in the long run. |
In order to use the same HTML in a testcase with several css files that are checked out of our source code repository I'd like to be able to put the following in a testcase:
and then in the regression runner, (using the array props feature in #64):
In order for this to work the sandboxing of iframes would need to have 'allow-scripts' added. However, the rasterization appears to be done before the scripts are run so something would need to be done to delay rasterization until the page is fully rendered. (I can work on this but I think I'll need some pointers as to where to look.)
The text was updated successfully, but these errors were encountered: