Summary of Changes

Intent

The bug addresses a regression where Fenix (Firefox for Android) cold start app-link navigation timing telemetry stopped reporting correctly. This happened because the pageload event was previously moved to fire at page destruction (bug 2042702), at which point the may already be discarded. Since the app-link launch type was stored on the , it was no longer available when the pageload event was actually recorded, causing the telemetry data to be lost.

Solution

The fix changes the storage mechanism for the Android app-link launch type from being stored on to a dedicated parent-process-side hash map keyed by load identifier.

New storage mechanism: A static is introduced in (behind ), along with two functions: to insert a launch type keyed by load id, and to retrieve and remove the stored value. Both operations are asserted to run on the main thread in the parent process.

Storing the launch type: In (parent-side), when a non-zero app-link launch type is present on the load state, it is now stored in this new map keyed by the load state's load identifier, instead of being set on the .

Capturing the load identifier in the document: During , the document now captures the load identifier from its into a new member . The itself stores the load identifier from the at the beginning of .

Sending the load identifier with the pageload event: The IPC message is updated to pass the load identifier instead of a . When the document is destroyed and fires, it sends the captured load identifier.

Consuming the launch type on the parent: In , the stored app-link launch type is retrieved (and removed) from the map using the load identifier, then passed directly to . This eliminates the need to look up the and the risk of it being discarded.

Cleanup of old approach: The field, its getter/setter, and the transfer logic during BC replacement (COOP swaps) are all removed from , as they are no longer needed.