Make history.length Fission compatible
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | fixed |
People
(Reporter: smaug, Assigned: smaug)
References
(Blocks 1 open bug)
Details
(Whiteboard: [7/14] patch r+, ready to land)
Attachments
(2 files, 1 obsolete file)
history.length is from web page point of view synchronous, but once session history lives in the parent process, we can't get the information synchronously.
My current plan is to store length in (each) top level browsing context.
If a child process does an operation which would add something to the session history synchronously (for example pushState), child sends an async message with return value (== MozPromise) to parent process. The history.length becomes the cached length + pending MozPromises.
(This also shouldn't have the webcompat issues 1/2+pushState count and similar approaches would have)
This can be emulated even without session history in parent and assertions can be added whether the behavior of the new implementation matches the old one.
Updated•6 years ago
|
| Assignee | ||
Comment 1•6 years ago
|
||
| Assignee | ||
Comment 2•6 years ago
•
|
||
Comment 3•5 years ago
|
||
Deferring to Fission Nightly (M6) because this is related to session history.
| Assignee | ||
Updated•5 years ago
|
| Assignee | ||
Comment 5•5 years ago
|
||
Depends on D78814
| Assignee | ||
Comment 6•5 years ago
|
||
Depends on D79197
Updated•5 years ago
|
| Assignee | ||
Comment 7•5 years ago
•
|
||
Comment 9•5 years ago
|
||
| Assignee | ||
Comment 10•5 years ago
|
||
Aha, the push just revealed a bug in https://hg.mozilla.org/mozilla-central/rev/15e2f6e7ea2f
| Assignee | ||
Comment 11•5 years ago
|
||
Comment 12•5 years ago
|
||
Comment 13•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/a55eebd5cb97
https://hg.mozilla.org/mozilla-central/rev/75f5953053de
Description
•