Previously, a static build would produce three separate files:
QtWebKit.a, libjscore.a and libwebcore.a. These seem to have
dependencies on each other and this caused the build errors on Linux.
This change means that the sources of jscore and webcore are both built
directly into the QtWebKit.a target. libjscore.a and libwebcore.a are no
longer built. It is then possible to create a static binary on Linux.
http://code.google.com/p/phantomjs/issues/detail?id=413
We use the Qt Meta Object system to create an easily accessible QVariantMap
representation of the Key enumerator, such that we can now write something
like for example
page.sendEvent(keypress, phantom.keys.Backspace);
http://code.google.com/p/phantomjs/issues/detail?id=492
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.
This is still needed so that injectJs() methods work with CoffeeScript
and so that the main script file can be in CoffeeScript.
It causes duplication of code and some consideration is needed as to
how we could refactor the old inject code so that it uses modules
underneath. Lots of the module functionality written in JS could replace
the old C++ code (CSConverter, most functions in Utils).
http://code.google.com/p/phantomjs/issues/detail?id=47
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
nativeRequire() has been refactored so that native modules are also
wrapped in Module objects. Additionally, native modules are also
cached and included in stack traces if an error occures inside them.
Phantom::loadModuleSource() has been renamed to
Phantom::readNativeModule() so that it's clear that it's used only to
load native modules.
Finally, all the require() code has been move after setting error
handlers in bootstrap.js so that if an error occurs in the require()
code, the stack trace is printed.
http://code.google.com/p/phantomjs/issues/detail?id=47
Instead of trying to use sourceId to determine what module threw an
error, we now load module's source code using modified
QWebFrame::evaluateJavaScript and leverage PhantomJS's stack traces.
http://code.google.com/p/phantomjs/issues/detail?id=47
Most of the tests passed after merging almost unchanged phantomjs-nodify
code, some needed small changes. The one that is still failing is for
CoffeeScript modules.
http://code.google.com/p/phantomjs/issues/detail?id=47
For some reason, it seems that checking CONFIG(static) inside
src/phantomjs.pro is not reliable. That caused the STATIC_BUILD define
not to be set, and hence Q_INIT_RESOURCE would never get called in
main.cpp.
Instead of using Q_INIT_RESOURCE, let's just compile the resources
directly into the phantomjs binary. This means we don't need to detect
whether Qt is linked statically or dynamically.
https://code.google.com/p/phantomjs/issues/detail?id=430
Debug mode turns off all optimisations. This make PhantomJS considerably
slower.
Instead, we build in 'release' mode, but generate debugging symbols at
the same time.
This may present some problems analysing crashes, if the optimisations
make that difficult. However, in my testing I was able to get useful
debug output even with optimisations enabled. So we should see how we go
- if it becomes a problem we can produce seperate debug binaries with no
optimisations.
https://code.google.com/p/phantomjs/issues/detail?id=599
This provides support for compiling the breakpad client into PhantomJS,
and generifies that Linux packaging scripts so that they also apply to
OS X and automate the symbol generation.
Building the Breakpad tool programs seems to be less than
straightforward on OS X, and documentation is poor. We have managed to
produce tools/dump-syms-mac.pro which allows building the dump_syms
program for dumping the debugging symbols. This needed a couple of
modifications to breakpad in order to compile successfully.
We have run out of time to work on making the minidump_stackwalk program
build. However, this is solely a developer tool and so it can wait until
after the 1.6 release before we complete this work.
Testing is welcome!
https://code.google.com/p/phantomjs/issues/detail?id=576
When console.error was called, there was a segfault because it was
treated as an uncaught exception, but did not have the correct stack
trace information (I am not sure why, but still...)
Now that we are generating the stackTrace in WebCore::reportException,
the MessageType gets set correctly, so we can use this to differentiate
between uncaught exceptions and other messages.
https://code.google.com/p/phantomjs/issues/detail?id=47
On reflection, this approach seems like a bad idea and a source of bugs.
I think passing object references between pages seems inherently
problematic, and we are better off just passing data to the onError
handler. If users need the actual object reference, they are able to use
try ... catch within the page.
This change also means that we are no longer breaking backwards
compatibility with the page.onError function signature.
WebCore already has a bunch of plumbing to pass around stacks. This
exists for the inspector/console. However, we need to actually retrieve
the error stack in WebCore::reportException.
To achieve this, I am attaching a stackArray property to the error
object. This is not as clean as I'd like, but seems ok for now. (We
should not document stackArray though.)
https://code.google.com/p/phantomjs/issues/detail?id=166
1. Passing JavaScript eval and other related actions to the CurrentFrame, not the MainFrame.
2. Added different methods to navigate between frames
3. With a call to "window.frames[0].focus()", the "currentFrame" changes: commands after that are sent to the new frame under focus.
4. The navigation between frames allows to walk over the "tree of frames" contained in the page.
This commit also adds examples (both in JS and CoffeeScript) and Unit Test.
http://code.google.com/p/phantomjs/issues/detail?id=573
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
Ariya Hidayat