We are linking against e.g. libQtCore.so.4 rather than
libQtCore.so.4.8.2, and this affects symbol generation. (I am not sure
if this changed at some point, but this change should make it generate
the correct symbol files regardless.)
Also makes it less dependent on the Qt version.
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).