293173 - Inconsistent handling of prescontext's link handler and container

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Before bfcache we have the invariant that the prescontext's link handler and
container are both the same -- the docshell.   With bfcache, we null out the
link handler but not the container in cached presentations.  We should sort our
exactly what these do and figure out whether we should be nulling both, neither,
or only one and why, then document it.

I also think we should just nuke both members and use the document's container,
but that may confuse printing....

Comment 1

[Brian Ryner (not reading)]

Attachment: null out the prescontext container

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 186773 [details] [diff] [review]
null out the prescontext container

r+sr=dbaron, assuming it doesn't need to be re-set elsewhere :-)

Comment 3

[Brian Ryner (not reading)]

Comment on attachment 186773 [details] [diff] [review]
null out the prescontext container

Requesting approval; only impacts fastback.

Comment 4

[Brendan Eich [:brendan]]

Comment on attachment 186773 [details] [diff] [review]
null out the prescontext container

a=me for 1.8b3.

/be

Comment 5

[Brian Ryner (not reading)]

checked in

Comment 6

[Boris Zbarsky [:bzbarsky]]

I'd still like to see some documentation on what these members are and why just
nulling out both makes sense (in particular why no one ever assumes they're
non-null, which they generally are in normal browsing).