1541812 - nsPref:changed fired before toplevel-window-ready, or possibly marionette-startup-requested not firing, causing Marionette to fail to initialise

Status: RESOLVED DUPLICATE of bug 1382162

(Remote Protocol :: Marionette, defect)

Description

[Andreas Tolfsen ❲:ato❳]

Over in https://bugzilla.mozilla.org/show_bug.cgi?id=1483559#c11,
Kriti reports that she’s having trouble running the WPT wdspec
tests. See the attached the verbose logs.

The interesting part:

 0:47.30 pid:5690 1554318336190 Marionette  TRACE   Received observer notification profile-after-change
 0:48.35 pid:5690 1554318337244 Marionette  TRACE   Received observer notification command-line-startup
 0:48.35 pid:5690 1554318337245 Marionette  TRACE   Received observer notification nsPref:changed
 0:48.35 pid:5690 1554318337245 Marionette  DEBUG   Init aborted (running=false, enabled=true, finalUIStartup=false)
 0:52.64 pid:5690 1554318341529 Marionette  TRACE   Received observer notification toplevel-window-ready

I find reasoning about testing/marionette/components/marionette.js
hard, but from what I can tell this.init() is usually called right
after the statement this.finalUIStartup = true;, which should
allow it to proceed.

The exception is when nsPref:changed is fired:

      case "nsPref:changed":
        if (this.enabled) {
          this.init(false);
        } else {
          this.uninit();
        }
        break;

Because this.init() doesn’t remove the toplevel-window-ready
observer, I would expect this code to get run immediately after the
first init is aborted:

      case "toplevel-window-ready":
        subject.addEventListener("load", ev => {
          if (ev.target.documentElement.namespaceURI == XMLURI_PARSE_ERROR) {
            Services.obs.removeObserver(this, topic);

            let parserError = ev.target.querySelector("parsererror");
            log.fatal(parserError.textContent);
            this.uninit();
            Services.startup.quit(Ci.nsIAppStartup.eForceQuit);
          }
        }, {once: true});

Assuming the subject here is an nsIDOMWindow, we proceed to wait
for the DOM load event which then doesn’t check if the window’s
readyState is complete, but it doesn’t seem to be a problem if
the load event doesn’t fire.

The one event we don’t see is marionette-startup-requested,
which seems to short-circuit the toplevel-window-ready check by
removing its listener, sets this.finalUIStartup to true, and then
calls this.init().

Comment 1

[Andreas Tolfsen ❲:ato❳]

Kriti are you certain you’re using an up-to-date Firefox build?
Could you try ./mach clobber && ./mach build to be sure? The
changes to marionette-startup-requested are pretty recent.

whimboo, have you seen anything like this before?

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This is exactly bug 1382162 and what we aren't able to reproduce yet. I would appreciate if Kriti could help us with investigation.

Comment 3

[Andreas Tolfsen ❲:ato❳]

Ah thanks!

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Clearing the needinfo request in favor of bug 1382162.