[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [atf-dev] Browser Window is always disabled when suspended at a js breakpoint
|
Bob,
Thanks for replying on this subject. I was specifically referring to where the nsIBaseWindow is disabled below:
Snippet taken from org.eclipse.atf.mozilla.ide.debug.internal.model.JSDebugThread.java lines 482-489. This happens in the "onExecute" hook function.
nsIBaseWindow window = (nsIBaseWindow)getDebugTarget().getProcess().getAdapter(nsIBaseWindow.class);
try {
// Prevent user from taking further actions within the browser while suspended
window.setEnabled(false);
} catch (XPCOMException xpcome) {
if (xpcome.errorcode != Mozilla.NS_ERROR_NOT_IMPLEMENTED)
throw xpcome;
}
This is the code I'm referring too which will disable the Browsre window that the currently paused _javascript_ thread is executing in. If I simply comment out that line, then the browser works as expected. So it seems that a deliberate decision was made to "turn off" the browser window where the current _javascript_ debugger is suspended at.
Any thoughts? I think my 2 questions that I posted before will make more sense now if you look at that snippet I posted.
Thanks for your response,
Greg
On 7/23/07,
Robert Goodman <goodmanr@xxxxxxxxxx> wrote:
Greg
ATF isn't doing anything to disable
the other browser. The behavior you described seems to be a limitation
of the Mozilla debug interface and the fact that everything in eclipse
is running in the same process. We have tried to work around the problem
but don't have a solution yet. The hang is occurring in the XULRunner browser.
One of the thing we want to do, but haven't had time is pull XULRunner
into the c debugger and see if we can find why the hang is occurring. This
may gives us some hints on how to work around the problem.
Thanks
Bob
Robert Goodman
goodmanr@xxxxxxxxxx
Hello,
Nice job on the current _javascript_ debugger implementation. Its been
awhile since I have looked at it and it now has some really nice stuff
in there. I've been getting up-to-speed with how it interacts with
the Mozilla browser when stepping through _javascript_ code. One thing
I noticed is that when you are suspended at a _javascript_ breakpoint, all
user-input is disabled for the associated browser window. I found
this in the code at JSDebugThread.java line 485. In a comment it
states that the user is being prevented from further actions within the
browser while suspended.
There are 2 questions that I have regarding this behavior, that I would
like some feedback on:
1. What
was the reasoning or what discussion led to this policy decision of always
disabling the browser window?
2. Are
there any other factors in the _javascript_ debugger that make the window
browser being disabled a requirement?
One reason I asked #2 is because, lets say, that I wanted
to change it so the browser window is always enabled. Would there
be any side-effects or other consequences of that choice?
Thanks again guys for making this _javascript_ debugger implementation available
for us to have these discussions. I appreciate any response.
Greg_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev
_______________________________________________
atf-dev mailing list
atf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/atf-dev
