1650679 - `can't access property "windowUtils"` when opening a window that includes a wizard

Status: RESOLVED DUPLICATE of bug 1669666

(Toolkit :: UI Widgets, defect)

Description

[Philipp Kewisch [:Fallen][📱📆]]

The onWindowCreated listener gets the window from the event target, assuming this is always the pageshow event of the window.

This causes the following error if the window contains a wizard. The wizard's pageshow event is meant to indicate that a wizard page is shown and is fired here:

TypeError: can't access property "windowUtils", window is undefined
    getWindowID resource://devtools/server/actors/targets/browsing-context.js:86
    onWindowCreated resource://devtools/server/actors/targets/browsing-context.js:1767
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:103
    _fireEvent chrome://global/content/elements/wizard.js:484
    set currentPage chrome://global/content/elements/wizard.js:197
    advance chrome://global/content/elements/wizard.js:326
    _maybeStartWizard chrome://global/content/elements/wizard.js:422
    _registerPage chrome://global/content/elements/wizard.js:401
    connectedCallback chrome://global/content/elements/wizard.js:500

To reproduce, simply go to the browser console and enter MigrationUtils.showMigrationWizard().

Comment 1

[Jason Laster [:jlast]]

Out of curiosity, how did you stumble on this?

If you look at the call stack you'll see you're mostly in browser UI and devtools server code. We would not expect these utilities to have the window, but i'm curious what brought you here :)

Comment 2

[Logan Smyth [:loganfsmyth]]

This seems to be because the wizard is reusing the pageshow event in https://searchfox.org/mozilla-central/rev/7ec7ee4a9bde171ba195ab46ed6077e4baaef34d/toolkit/content/widgets/wizard.js#197, but not dispatching it on a Window, and is instead dispatching it on an element and letting it bubble up, meaning that evt.target is not a Window like we assume it will be, and like the event specification defines it to be.

It seems like that event should not be used in the way that it currently is, but I can't say if it's just a name conflict, or if it's meant to work similarly to the normal pageshow event or what.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The product::component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Comment 4

[Philipp Kewisch [:Fallen][📱📆]]

I noticed this in Thunderbird while I was trying to reduce error console messages. We have a few more wizards there.

The wizard is reusing pageshow, it doesn't have any connection to the window's pageshow event. The name was likely chosen back in the days because a <wizard> has <wizardpage> elements, so the event fires when flipping through those pages. There is likewise a pagehide event.

This may have surfaced in combination with the fact that <wizard> used to be the top level document element, but this was changed somewhere in the xul to xhtml conversion so that <wizard> is the first child of a <window> element.

I seem to recall there are only two wizards left in Firefox, but on the other hand this should be a fairly simple fix in devtools code.

Comment 5

[Jason Laster [:jlast]]

Thanks!

Comment 6

[Logan Smyth [:loganfsmyth]]

Alex, any thoughts on this?

Comment 7

[Alexandre Poirot [:ochameau]]

We listen for pageshow from here:
https://searchfox.org/mozilla-central/source/devtools/server/actors/targets/browsing-context.js#1693
And this event is processed over there:
https://searchfox.org/mozilla-central/rev/c86c19bd64f8f19590a4190c282781d3a9631422/devtools/server/actors/targets/browsing-context.js#1755-1785
We should probably try to ignore this fake pageshow event in this onWindowCreated function.
Take into account that this function process both DOMWindowCreated and pageshow events.
Then, we would most likely have to add a similar bail out code in onWindowHidden.

I think it is fine letting the wizard code emit "surprising" pageshow event and we can just make the devtools code more resilient to the unexpected.

Comment 8

[Julian Descottes [:jdescottes]]

Working on this in Bug 1669666