This came up while working on bug 1578465.

We currently don't fire onLocationChange for remote subframe location changes.

I assume this will include OnContentBlockEvent too? We need that for bug 1590696.

This is in-turn blocking the trackingUI M-fis tests.

Kris, are you still working on this onLocationChange bug? It's blocking some M4.1 mochitests (such as bug 1592777). Can we delegate this bug to a different Fission engineer?

(In reply to Chris Peterson [:cpeterson] from comment #3)

Kris, are you still working on this onLocationChange bug? It's blocking some M4.1 mochitests (such as bug 1592777). Can we delegate this bug to a different Fission engineer?

Not actively. My understanding is that it's not currently blocking anything, so it hasn't been a high priority. If it is blocking something, someone will need to explain to me what and why.

(In reply to Kris Maglione [:kmag] from comment #4)

Not actively. My understanding is that it's not currently blocking anything, so it hasn't been a high priority. If it is blocking something, someone will need to explain to me what and why.

Ethan Tseng told me (three months ago, bug 1592777 comment 3) the browser_popupNotification_3.js test (bug 1592777) was blocked waiting for this onLocationChange fix. I will confirm with MattN, triage owner for that popup test.

cpeterson will confirm why browser_popupNotification_3.js test (bug 1592777) needs this onLocationChange change.

unassigning kmag in the meantime

(In reply to Chris Peterson [:cpeterson] from comment #6)

cpeterson will confirm why browser_popupNotification_3.js test (bug 1592777) needs this onLocationChange change.

The test needs location change events because it is testing that a location change in a background tab dismisses a notification and that a location change in an embedded frame does not.

https://searchfox.org/mozilla-central/rev/61fceb7c0729773f544a9656f474e36cd636e5ea/browser/base/content/test/popupNotifications/browser_popupNotification_3.js#305

@ Matt, IIRC you were proposing some changes to RemoteWebProgress a couple months ago. What is the current state of RemoteWebProgress and Fission? Is there an alternative tests should use?

Can we listen for the "window-global-created" observer notification, that fires when we create a new WindowGlobalParent (and make it the current window for a BrowsingContext)?

Assigning to Kashav because he volunteered to work on this bug.

Ended up going with the thing Matt suggested in comment #8 for bug 1592777. This bug has no other dependencies, so we probably don't actually need this. We can re-open if it's needed in the future.