1751541 - GeckoView:StateUpdated:historychange seen before GeckoView:LocationChange

Status: NEW

(GeckoView :: General, defect, P3)

Description

[:Grisha Kruglov]

Ran into this in Fenix, and I'm wondering if the order of these events can even be relied upon.

What I've observed:

• on a direct navigation in Fenix (on some tab, via the awesomebar navigate directly to some url; this replicates well with yandex.ru)
• in Fenix, we process UpdateHistoryStateAction before we receive UpdateUrlAction
• which I've traced down to GeckoView:StateUpdated (for the historychange variant) being received in GeckoSession before GeckoView:LocationChange
• in that specific scenario (loading yandex.ru on some tab with some other page loaded), I see the following sequence: HistoryChange, then LocationChange, then again HistoryChange.

In some Fenix code, we semi-explicitly rely on the ordering of these events: we expect that tab's url is set to what the user navigated to while processing UpdateHistoryStateAction.

I also do not see this behaviour on current release, but it's easily reproducible on Nightly (v98, Jan 21st).

Comment 1

[[ex-Mozilla] Agi Sferro | :agi]

I agree, receiving a historychange before LocationChange is a little weird, but I'm not sure we can have any sort of guarantees given how separated are the two systems.

Andreas, would you happen to know (or know somebody who knows) why we are now receiving history events before onLocationChange?

Comment 2

[Andreas Farre [:farre]]

I'm guessing that this might be related to Session History in the Parent (SHIP), and if so, then :smaug or :peterv would know more.

If not, I can look a bit harder at it.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

I assume this happens without SHIP, given that this is about Fenix.

Comment 4

[Emily Toop (:fluffyemily)]

Andreas, if this is not SHIP, then have you any ideas what else might be the cause?

Comment 5

[Andreas Farre [:farre]]

How much is this an issue with the Fission/SessionStore/SHIP work for Android now?