1546759 - Change nsSHistory::WalkHistoryEntries to walk browsing context tree instead of doc shell tree

Status: RESOLVED FIXED

(Core :: DOM: Navigation, enhancement, P2)

Description

[Anny Gakhokidze [:annyG]]

To accomodate recent session history changes, we need to change nsSHistory::WalkHistoryEntries to walk browsing context tree instead of doc shell tree

Comment 1

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 1: Walk BrowsingContext tree in nsSHistory::WalkHistoryEntries, instead of docshell,

Comment 2

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 2: Add mOSHE and mLSHE to BrowsingContext and update them appropriately,

Depends on D42991

Comment 3

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 3: Add an IPC call from parent to child in PContent.ipdl to swap history entries in docshell,

Depends on D42992

Comment 4

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 4: Add a method for swapping history entries to Browsing Context,

Depends on D42993

Comment 5

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 5: Move SetChildHistoryEntry to parent process,

Depends on D42994

Comment 6

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 6: Move CloneAndReplaceChild to parent process,

Depends on D42995

Comment 7

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 7.1 Update nsDocShell::SetHistoryEntry to call ::Top(),

Depends on D42996

Comment 8

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 7.2 Consolidate calls inside of nsDocShell::SetHistoryEntry,

Depends on D42997

Comment 9

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 8: Consolidate several IPC calls such that CloneAndReplace is called from parent again,

Depends on D42998

Comment 10

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Part 9: Make SetChildHistoryEntry and CloneAndReplaceChild fission compatible,

Depends on D42999

Comment 11

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Change nsSHistory::WalkHistoryEntries to walk browsing context tree instead of doc shell tree, r=peterv

TODO currently coming up with a great and extended commit message

Comment 12

[Chris Peterson [:cpeterson]]

Deferring to Fission Nightly (M6) because Anny says this bug doesn't need to block dogfooding (M5).

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6ebc7618a5fa
Change nsSHistory::WalkHistoryEntries to walk browsing context tree instead of doc shell tree, r=peterv,nika

Comment 14

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/6ebc7618a5fa

Comment 15

[Calixte Denizet (:calixte)]

There are 8 crashes with signature mozilla::dom::ContentParent::RecvUpdateSHEntriesInBC.
The moz_crash_reason is MOZ_DIAGNOSTIC_ASSERT(false) (Trying to update a child BrowsingContext in another child process).

Comment 16

[Anny Gakhokidze [:annyG]]

I think we are hitting this assertion because the BC we are trying to update is discarded thus is no longer owned by this process. Currently working on a patch.

Comment 17

[Anny Gakhokidze [:annyG]]

Attachment: Bug 1546759 - Do not update session history entries in BC when it is discarded, r=peterv

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acfafba3fdcc
Do not update session history entries in BC when it is discarded, r=peterv

Comment 19

[Anny Gakhokidze [:annyG]]

Calixte, I was wondering why this bug was re-opened? When a patch causes regressions don't we usually just file new bugs and mark them as regressions of this bug? I am not an expert on how this works so I am just wondering.

Comment 20

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/acfafba3fdcc

Comment 21

[Calixte Denizet (:calixte)]

:annyG, the crash reason is an assert you purposefully added to help you to fix the original bug so no need to file a new bug.

Comment 22

[Anny Gakhokidze [:annyG]]

I understand :) Thank you!

Comment 23

[Ryan VanderMeulen [:RyanVM]]

We're still seeing some ongoing crashes with this signature. Is that being tracked anywhere?

Comment 24

[Chris Peterson [:cpeterson]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #23)

We're still seeing some ongoing crashes with this signature. Is that being tracked anywhere?

I just filed bug 1624012 to track these crashes.