When history is purged, a session state update should be triggered
Categories
(Firefox :: Session Restore, enhancement, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox131 | --- | fixed |
People
(Reporter: kaya, Assigned: kaya)
References
Details
Attachments
(1 file)
According to the logs I get for the purgeHistory flow, I observed that even though we are calling frameLoader.requestSHistoryUpdate, we do not receive a onTabStateUpdate callback.
This was revealed in one of the failing gv-junit tests that GeckoView had while I was working on SHIP on Android ticket (see Bug 1677190). After debugging desktop, I observed a similar behavior as well and that's why I'm reporting the bug here. Not sure about if I chose the correct component, please correct it if necessary.
Comment 1•2 years ago
|
||
What is the entry point for the purgeHistory flow here. Is this being triggered via clear history in preferences UI or something else? What is the user-observable bug here? Or are we just too slow to update the serialized state after this action?
| Assignee | ||
Comment 2•2 years ago
|
||
I used Clear Recent History from the History option on app's the toolbar (or from the three dot menu on the right top). I added some logs in SessionStore file, e.g. to the places that I linked in the description (requestSHistoryUpdate, onTabStateUpdate), and realized that we are not receiving any state update after we Clear Recent History. This is not a user-observable bug. When users navigate to History after clearing it, my guess is that they've probably already received state update and updated the history item list so there's no observable bug. That's why I opened this as an enhancement ticket.
When it comes to Android:
before SHIP-> after we clear the history, we get a state update where we update the state cache with that. And the failing gv-unit test (as linked in the description) was testing that behavior, i.e. calling GeckoSession::purgeHistory and receiving a state update after the operation is done.
SHIP enabled Android -> this time, we clear the history, try to add the timer that triggers the state update, but it returns here and the state update never received. I first thought this was Android-only behavior but after checking it out on Desktop, I realized desktop has a similar behavior. After discussing this with Peterv, we thought of having a separate ticket for this, and handle it that way for both platforms, if necessary.
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
| bugherder | ||
Description
•