* Addresses [Issue 678](http://code.google.com/p/phantomjs/issues/detail?id=678)
* "page.close()" deprecated "page.release()"
* the callback "onClosing(page)" gets back the reference to the closing page - that can be ideal to have 1 handler for all the page that close
* It works both when closing directly the page, or if the page closes by itself
* If parent closes, child close too
Tests provided.
This addresses [Issue #151](http://code.google.com/p/phantomjs/issues/detail?id=151).
Summary of the new API:
- page.pages[]
- page.pagesWindowName[]
- page.getPage(windowName)
- page.windowName
- page.onPageCreated = function(newPage) { ... }
The page object created by the user holds responsibility of the "child" pages it creates.
If a page closes (i.e. window.close()) or a call to "page.pages[i].release()" is done,
the array "page.pages[]" will automatically update to contain only the pages still open.
Instead of using a C++ wrapper, I used a Node version of CoffeeScript
with a small JS wrapper (src/modules/_coffee-script.js). This way, since
the module system is similar enough to the Node.js module system, I only
need to require CoffeeScript in bootstrap.js and all the support for
.coffee is added by CoffeeScript itself.
To include a newer version of CoffeeScript in the source tree, see
tools/import-coffee-script.sh.
http://code.google.com/p/phantomjs/issues/detail?id=47
The callback is harmless: if the user registers a "page.onCallback = [Function]",
that will receive any JS type passed via "phantomCallback()".
Also, if the handler for ".onCallback" returns a value, that is passed back as a
return value of "phantomCallback()".
Also, added "page.onConfirm" and "page.onPrompt".
This solves [Issue #133](http://code.google.com/p/phantomjs/issues/detail?id=133).
This is useful in case:
* we don't care about the result of the evaluate
* we don't need to have the result of the evaluate on the spot
* we need the stack of execution to begin WITHIN the page
Also, linting code: everyone should use a linter when writing Javascript. Everyone.
http://code.google.com/p/phantomjs/issues/detail?id=593
Note that for errors that occur within subpages, this object is not the
real error object, but a copy. This is because the real object exists
within the subpage, but the page.onError handler runs within the main
context, so we have to pass it through as data.
https://code.google.com/p/phantomjs/issues/detail?id=166
commit c373ac4d17814588f4e3344f634ec469e56c0303
Author: Danny Wang <wangyang0123@gmail.com>
Date: Tue Apr 10 12:38:13 2012 +0800
moved i and l delarations to the top of page.evaluate()
commit bf24d4d1ecdb9e06c7bf461e87c222b10b74bc9d
Author: Danny Wang <wangyang0123@gmail.com>
Date: Tue Apr 10 08:54:55 2012 +0800
fixed defects in evaluate() pointed out by detro
commit 0bb8cff7803b70fe60fd761b1b748b5510705ee0
Author: Danny Wang <wangyang0123@gmail.com>
Date: Fri Apr 6 19:21:47 2012 +0800
added passing variables to function for page.evaluate
http://code.google.com/p/phantomjs/issues/detail?id=132
add a default error handler on all pages. people can override if they
need.
ensure error handler can be removed without errors.
Hack ScriptSourceCode so we can pass in a raw string and not have it
validated as a URL
change source location hint for webpage.evaluate().
http://code.google.com/p/phantomjs/issues/detail?id=166
Please enter the commit message for your changes. Lines starting
The recent patch that brought asynchronous webserver response handling
made it impossible to have proper keep-alive support in the server.
We want the server to support keep-alive though, which is especially
useful when writing a PhantomJS script that allows one to "remote control"
PhantomJS, using the WebServer API, without flooding the TCP connections.
Also the performance might be improved.
Note: This patch reverts commit bbce8920d0,
and resets the Mongoose code to the vanilla 3.0 version. Instead we now
support the async handling of HTTP requests using some QWaitCondition
magic.
Note: keep-alive support is optional, and disabled by default. To enable
it, use something like:
server.listen(port, {"keep-alive": true}, function(request, response) {...});
Like before, calling response.close() is crucial. Furthermore though, a
server that has keep-alive enabled *must* set a proper "Content-Length: ..."
header in it's response, otherwise clients will not be able to know when
the response has finished.
fix memory leaks in webserver
ISSUE: 416 (http://code.google.com/p/phantomjs/issues/detail?id=416)
CommonJS proposal: http://wiki.commonjs.org/wiki/Filesystem/A.
It's called "raw".
http://code.google.com/p/phantomjs/issues/detail?id=400
Squashed commit of the following:
commit dd5fab4778bb7b67f1eca26a07d430aadd458c6e
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Thu Feb 23 16:19:21 2012 +0100
the "mode" string is now properly parsed, and not only the first
char evaluated. This allows us to do fancy things like
fs.open(file, "rw+"); // read/write/append
Furthermore .read() is adapted such that it will always return the
full file contents, no matter where we have seeked to before (i.e.
by passing + we seek to the end, hence read() would always return
an empty string).
To open a binary file, pass "b" in the mode string to fs.open, e.g.:
fs.open(file, "rb"); // read binary
fs.open(file, "wb"); // write binary
fs.open(file, "rwb+"); // read/write binary, append
alternatively, one can use these shortcuts:
fs.write(file, contents, "b"); // write binary
fs.read(file, "b"); // read binary
Unit tests are extended and the echoToFile.js example fixed (it did not
close the file, which lead to the contents never getting written
on-disk since flush() is never called).
Also note that the FileSystem::open method was cleaned up and at least
one memory leak (if QFile* could not open) was fixed. The code should
now also be more C++-like.
commit 41139951138491459accefab22d48eba7b0b9900
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Wed Feb 15 16:39:23 2012 +0100
use QString instead of QByteArray for raw binary data
QByteArray is simply unusable in JavaScript, since functions like
e.g. window.btoa expect a string. Also there is no sane way to
create a byte array in javascript, as ArrayBuffer e.g. is not
supported by QScript (at least there is no conversion in place).
If we use QString and some custom read/write code this all works
as expected though, we can use window.btoa to base64 encode binary
data and we can create random binary data using String.fromCharCode
also adds a unit test
commit e45673486ef27daf916902153217f9e5001b68c9
Author: Milian Wolff <milian.wolff@kdab.com>
Date: Wed Feb 15 14:39:15 2012 +0100
make it possible to read/write raw/binary files
this adds File::readRaw and File::writeRaw functions,
as well as 'shimmed' versions FS::readRaw and FS::writeRaw
these functions directly use QFile and QByteArray instead of
QTextStream and QString, making it possible to read and write
binary data, e.g. images and such.
this is the minimal server that gets properly embedded into
the phantomjs space but the .listen api is missing actually
useful options (incoming request and ability to write to client)