1222558 - Mutation Observer callback is fired in the middle of script execution when running in devtools server

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Brian Grinstead [:bgrins]]

Attachment: testcase-mutation-walker.patch

STR:
Apply patch
Make sure 'remote debugging' and 'chrome debugging' are enabled in devtools settings
Open Browser Console
Open Browser Toolbox (ctrl+shift+alt+i)
Switch to Inspector panel (which runs the new script inside of the browser window's main process once the WalkerActor is instantiated)

Expected:
The script attached doesn't throw an exception

Actual:
It does (you can see the error in the Browser Console), which means the MO callback is fired during the script execution.  You can even see the call to `walker.nextNode()` in the stacktrace of the MO callback.

If I run the same script but in browser.js the problem doesn't happen.

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is the "devtools don't start a microtask when they start executing script" bug, no?  Pretty sure it's come up before with debugger evaluation....

Comment 2

[Brian Grinstead [:bgrins]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> This is the "devtools don't start a microtask when they start executing
> script" bug, no?  Pretty sure it's come up before with debugger
> evaluation....

Could be - we discussed a couple of related bugs earlier, although I was thinking that was *due* to debugger evaluation in scratchpad / console (like Bug 1081038).  In this case it's a script running in the main thread.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

main thread? All of MutationObserver stuff runs in main thread.

Comment 4

[Brian Grinstead [:bgrins]]

(In reply to Olli Pettay [:smaug] from comment #3)
> main thread? All of MutationObserver stuff runs in main thread.

Worded that poorly - I meant that this script is not executed as a string passed to the Debugger's executeInGlobalWithBindings as a Scratchpad or Console script would be (and I believe that was the case that 1081038 was hitting).

Comment 5

[Brian Grinstead [:bgrins]]

The js trace to the error is:

  WalkerActor<.initialize/observer<() inspector.js:1334
  WalkerActor<.initialize() inspector.js:1347
  constructor() heritage.js:146
  exports.InspectorActor<.getWalker</domReady() inspector.js:3640
  exports.InspectorActor<.getWalker<() inspector.js:3652
  actorProto/</handler() protocol.js:1013
  DSC_onPacket() main.js:1606
  DebuggerTransport.prototype._onJSONObjectReady/<() transport.js:479
  makeInfallible/<() DevToolsUtils.js:87
  makeInfallible/<() DevToolsUtils.js:87

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

So how is the code executed then?


(the issue doesn't happen in browser.js since that is using the normal DOM ways to execute scripts.)

Comment 7

[Brian Grinstead [:bgrins]]

(In reply to Olli Pettay [:smaug] from comment #6)
> So how is the code executed then?
> 
> 
> (the issue doesn't happen in browser.js since that is using the normal DOM
> ways to execute scripts.)

So the packet is received by transport.js[0] seems to be loaded via the Loader[1] from the server's main.js [2].  The require appears to be implemented by the addonsdk loader here [3].  I don't know this code, but it seems that it ends up finally loading the script here [4], using loadSubScript (it appears that 'source' is null in the case of loading actors which leads it to this path).

[0]: https://dxr.mozilla.org/mozilla-central/source/devtools/shared/transport/transport.js#474
[1]: https://dxr.mozilla.org/mozilla-central/source/devtools/shared/Loader.jsm#397
[2]: https://dxr.mozilla.org/mozilla-central/source/devtools/server/main.js#18
[3]: https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/toolkit/loader.js#571
[4]: https://dxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/toolkit/loader.js#278

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.