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

Status: RESOLVED WORKSFORME

(DevTools :: General, defect, P2)

Description

[Eric Shepherd [:sheppy]]

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.

Comment 1

[Eric Shepherd [:sheppy]]

Additional testing: the same thing happens in Web Console. Enter "alert('foo')" and execute it, and MDN scripts stop working.

Comment 2

[Eric Shepherd [:sheppy]]

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.

Comment 3

[Eric Shepherd [:sheppy]]

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.

Comment 4

[Mihai Sucan [:msucan]]

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.

Comment 5

[Rob Campbell [:rc] (:robcee)]

wiring in the tab modal dialog guy for a consult.

Comment 6

[Rob W]

Confirm on Win7 X64 - MDN works only upon restart.

Comment 7

[Mihai Sucan [:msucan]]

(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.

Comment 8

[Justin Dolske [:Dolske]]

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?

Comment 10

[Philip Chee]

Bug 682555 says the same thing is happening on bugzilla.mozilla.org

Comment 11

[Rob Campbell [:rc] (:robcee)]

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.

Comment 12

[Philip Chee]

Also isn't there a pref to turn off tabmodal alerts? Perhaps someone could test without those.

Comment 13

[David Chan [:dchan]]

alert() doesn't break MDN after changing
prompts.tab_modal.enabled to false

Comment 14

[Rob Campbell [:rc] (:robcee)]

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.

Comment 15

[Eric Shepherd [:sheppy]]

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.

Comment 16

[David Chan [:dchan]]

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

Comment 17

[David Chan [:dchan]]

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

Comment 18

[David Chan [:dchan]]

err, last comment should say
aWindow == null

aWindow is properly set when executing outside of webconsole.

Comment 19

[Rob Campbell [:rc] (:robcee)]

(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

Comment 20

[David Chan [: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.

Comment 21

[Rob Campbell [:rc] (:robcee)]

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.

Comment 22

[David Chan [:dchan]]

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

Comment 23

[Rob Campbell [:rc] (:robcee)]

Not sure Firebug's using evalInSandbox for its command line. I can check.

Comment 24

[Rob Campbell [:rc] (:robcee)]

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

Comment 25

[Kevin Dangoor]

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

Comment 26

[David Chan [:dchan]]

(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

Comment 28

[Brandon Benvie [:benvie]]

I believe this is resolved with bug 825039 landing.