Closed Bug 678971 Opened 13 years ago Closed 11 years ago

Running code in Scratchpad breaks MDN and bugzilla.mozilla.org until Firefox restart

Categories

(DevTools :: General, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: sheppy, Unassigned)

References

Details

(Whiteboard: [minotaur])

If I'm in the editor on MDN and run any code in a Scratchpad window, say, for example:

alert("foo")

MDN scripts stop running. I can't open drop-down menus, invoke the editor (save changes if I'm in the editor), etc.
Additional testing: the same thing happens in Web Console. Enter "alert('foo')" and execute it, and MDN scripts stop working.
Also, reloading the page doesn't fix the problem. Nor does shift-reload. I have to actually quit Firefox and restart it to make MDN start working again.
And I've now also confirmed that this happens even if I'm not in the editor when I run the script in Scratchpad and Web Console.
Confirmed. I can repro on Linux, 64 bits, in the latest code (pulled from fxteam).

It's not *any* code, it's the alert() call that breaks MDN for some reason. If you execute any other code, there's no problem.
OS: Mac OS X → All
Hardware: x86 → All
Version: 7 Branch → Trunk
wiring in the tab modal dialog guy for a consult.
Confirm on Win7 X64 - MDN works only upon restart.
(In reply to Rob W from comment #6)
> Confirm on Win7 X64 - MDN works only upon restart.

No browser restart needed. Just close/reopen the tab.
It would be helpful to try and reduce this down. Eg, does a simple page with an onclick handler break too, or does it need something more complex to trigger the MDN breakage? Does it break if you insert a prompt call literally into the page (eg add a button with onclick=alert, instead of the devtool environment)?

I can't think of an obvious reason why the this would break. Although the most likely candidate is that the nsGlobalWindow modal state call is getting confused, and is somehow different upon entering and exit. Try dumping/breakpointing in nsGlobalWindow::EnterModalState() and nsGlobalWindow::LeaveModalState(), and see if the JSContexts are the same or different?
Bug 682555 says the same thing is happening on bugzilla.mozilla.org
Summary: Running code in Scratchpad breaks MDN until Firefox restart → Running code in Scratchpad breaks MDN and bugzilla.mozilla.org until Firefox restart
this is being triggered by an alert again.

I wonder if there's some strange interaction between the sandbox and tabmodal alert dialogs? I think there's an eventloop spun up for the alert code. I wonder if the act of switching tabs and running something else is tearing down the previous sandbox and attaching it to the new context without properly closing down the alert's eventloop?

Should be easy to test.

Aquilax: Try using console.log in the web console instead of alert for your debugging while we figure this out.

Thanks for the reports.
Also isn't there a pref to turn off tabmodal alerts? Perhaps someone could test without those.
alert() doesn't break MDN after changing
prompts.tab_modal.enabled to false
ah, good thinking. Thanks for checking that out, David.

Dolske, any recommendations here? We might be able to replace alert() in the console and scratchpad with a different version. Maybe one that just wraps console.log() and forces the webconsole to appear.

alert debugging appears to be a popular thing.
More than just being popular for debugging, alert() gets used in code samples a lot, as a substitute for whatever the reader might want to do under some condition or another -- and those samples are likely to get run while the web console is open.
I set breakpoints at
nsGlobalWindow::EnterModalState()
nsGlobalWindow::LeaveModalState()

EnterModalState() is called after executing alert(1) in webconsole, however LeaveModalState() isn't called after clicking "OK", (topWin->mModalStateDepth continues to increment)

If I visit a webpage with alerts(), EnterModalState() and LeaveModalState() are called.

The fix may be as simple as adding a LeaveModalState() call, though I'm not sure where. Thanks for the tip :dolske 

Tested with Nightly 9.0a1 buildID 20110830112325
Looked into the bug more, the issue is more complex than a missing LeaveModalState() call.


1497 nsDOMWindowUtils::EnterModalStateWithWindow(nsIDOMWindow **aWindow)
1498 {
1499   *aWindow = mWindow->EnterModalState();
[1]

*aWindow is set to null after the call to EnterModalState()



6607   nsCOMPtr<nsIDOMWindow> callerWin;
6608   nsIScriptContext *scx;
6609   if (cx && (scx = GetScriptContextFromJSContext(cx))) {
6610     scx->EnterModalState();
6611     callerWin = do_QueryInterface(nsJSUtils::GetDynamicScriptGlobal(cx));
6612   }
...
6618   return callerWin;
[2]

GetScriptContextFromJSContext(cx) returns null which means callerWin is not set



1505 nsDOMWindowUtils::LeaveModalStateWithWindow(nsIDOMWindow *aWindow)
1506 {
1507   NS_ENSURE_ARG_POINTER(aWindow);
1508   mWindow->LeaveModalState(aWindow);
[3]

L1507 returns early due to *aWindow = null, 


[1] - http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1497
[2] - http://mxr.mozilla.org/mozilla-central/source/dom/base/nsGlobalWindow.cpp#6563
[3] - http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#1505
err, last comment should say
aWindow == null

aWindow is properly set when executing outside of webconsole.
(In reply to David Chan [:dchan] from comment #18)
> err, last comment should say
> aWindow == null
> 
> aWindow is properly set when executing outside of webconsole.

that probably has to due with the code being executed from a sandbox. We pass in the content window and its prototype as arguments at sandbox creation time.

See:

http://mxr.mozilla.org/mozilla-central/source/browser/devtools/webconsole/HUDService.jsm#4573
Assignee: nobody → dchan
This appears to be a dupe of bug# 647727 . 

My testing showed that MDN worked if I forced LeaveModalState() after an alert(), which makes me believe the 2 bugs are the same.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
yeah, that seems likely.

I'm wondering if we should do the work in our sandboxes to wrap a new alert() method that does something sensible?

adding to minotaur for triage.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Whiteboard: [minotaur]
The sandbox would need to wrap other tab modal things like prompt() as well, though I think it's less likely a user would run prompt() from webconsole. I noticed that FireBug didn't have this problem when running code from their console. Perhaps the GreaseMonkey / FireBug "fixes" could be picked up
Not sure Firebug's using evalInSandbox for its command line. I can check.
could someone retest this to see if it's still a problem?

David if you're not going to be working on it, dump it back in the pool.

Thanks!

filter on PEGASUS
Keywords: qawanted
I just reproduced this testing with the accordion on the right at cnn.com. The accordion works at first, run an alert() from scratchpad and the accordion no longer works in that tab.

Filter on PEGASUS
Keywords: qawanted
Priority: -- → P2
(In reply to Rob Campbell [:rc] (robcee) from comment #24)
> could someone retest this to see if it's still a problem?
> 
> David if you're not going to be working on it, dump it back in the pool.
> 
> Thanks!
> 
> filter on PEGASUS

Sorry for not working on the bug. Resetting assignee
Assignee: dchan+bugzilla → nobody
I believe this is resolved with bug 825039 landing.
Depends on: 825039
Status: REOPENED → RESOLVED
Closed: 13 years ago11 years ago
Resolution: --- → WORKSFORME
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.