Closed Bug 1541812 Opened 6 months ago Closed 6 months ago

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

Categories

(Testing :: Marionette, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1382162

People

(Reporter: ato, Unassigned)

Details

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

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?

Flags: needinfo?(kritisingh1.ks)
Flags: needinfo?(hskupin)

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

Status: NEW → RESOLVED
Closed: 6 months ago
Flags: needinfo?(hskupin)
Resolution: --- → DUPLICATE
Duplicate of bug: 1382162

Ah thanks!

Clearing the needinfo request in favor of bug 1382162.

Flags: needinfo?(kritisingh1.ks)
You need to log in before you can comment on or make changes to this bug.