941428 - Breakdown - UITour: UITour.jsm not e10s friendly

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Mark Hammond [:markh] [:mhammond]]

TBH I haven't even looked at the module itself, but the test itself certainly isn't e10s friendly - it includes the code:

    let contentWindow = Components.utils.waiveXrays(gTestTab.linkedBrowser.contentDocument.defaultView);
    gContentAPI = contentWindow.Mozilla.UITour;

which fails with |contentWindow.Mozilla is undefined|

Comment 1

[Chris Peterson [:cpeterson]]

Move old M2 P3 bugs to M4 (because tracking-e10s=m5+ flag doesn't exist yet).

Comment 2

[:Gijs (he/him)]

Opening Help > Firefox Tour doesn't work when e10s is enabled, so yeah, it seems like it's not just the test.

Comment 3

[:Felipe Gomes (needinfo for replies!)]

I think we should list the Tour URL to be opened as a non-e10s tab.

Comment 4

[Alex Gibson [:agibson]]

(In reply to :Felipe Gomes from comment #3)
> I think we should list the Tour URL to be opened as a non-e10s tab.

It's worth mentioning here: we are now using `mozUITour` events not just in the onboarding tour pages, but also on other product pages on (e.g https://www.mozilla.org/en-US/firefox/sync/). Outside of mozilla.org, they are now also being used on about:home snippets. I don't know if listing specific URL's is the right solution, going forward. There could likely be more pages using these events in the future (e.g. Hello product pages).

Comment 5

[:Gijs (he/him)]

Yeah, I'm also not sure why we shouldn't fix this properly - the whole system already heavily uses events, so naively, I would have thought creating the relevant forwarding solution for the events to make it to chrome would be the most effective way to fix this...

Comment 6

[Drew Willcoxon :adw]

Breakdown complete.