Closed Bug 1669961 Opened 1 year ago Closed 1 year ago

JSWindowActorChild .contentWindow getter returns a WindowProxy even when the inner window isn't current


(Core :: DOM: Content Processes, defect, P2)




84 Branch
Fission Milestone M7
Tracking Status
firefox84 --- fixed


(Reporter: jdescottes, Assigned: kmag)



(Keywords: perf-alert, Whiteboard: [marionette-fission-mvp])


(1 file)

In a JSWindowActorChild, this.document and this.contentWindow.document can point to different objects.

For instance, in the patch at , when the document has not yet reached the "complete" readyState, the two objects will be different. Example of differences:

  • this.document.readyState is "complete" while this.contentWindow.document.readyState is "loading"
  • this.document.location is null while this.contentWindow.location.href points to the expected URL

Looking at the implementation, the document getter is not relying on the contentWindow getter, which explains why the two objects can differ.

Is the difference intentional? If it is, are there guidelines or documentation to know when we should use this.document vs this.contentWindow.document?

Was clarified by a discussion on #Fission

this.document and this.contentWindow.document can be out of sync.
this.contentWindow is a windowproxy which might point to a window from another process.
Under some circumstances, this.document might point to a destroyed document, while this.contentWindow.document will point to the document of another window.

this.document should always be considered as the source of truth and used rather than this.contentWindow.document.

Could be interesting to mention at , but I'm not sure how to phrase the warning properly. Closing for now, feel free to reopen if anyone wants to update the doc.

Closed: 1 year ago
Resolution: --- → INVALID
Resolution: INVALID → ---
Summary: JSWindowActorChild document and contentWindow.document can point to different objects → JSWindowActorChild .contentWindow getter returns a WindowProxy even when the inner window isn't current
Fission Milestone: --- → ?
Whiteboard: [marionette-fission-mvp]
See Also: → 1670332
Assignee: nobody → kmaglione+bmo
Severity: -- → S3
Type: task → defect
Fission Milestone: ? → M7
Priority: -- → P3
Pushed by
Return null from `.contentWindow` when inner window is inactive. r=nika

Backed out for causing crashtests due to windowUtils not being accessible



failure log:

[task 2020-10-22T19:49:04.674Z] 19:49:04 INFO - REFTEST INFO | SET PREFERENCE pref(browser.send_pings,true)
[task 2020-10-22T19:49:04.674Z] 19:49:04 INFO - REFTEST TEST-LOAD | file:///Users/cltbld/tasks/task_1603395997/build/tests/reftest/tests/docshell/base/crashtests/1257730-1.html | 34 / 3856 (0%)
[task 2020-10-22T19:49:04.680Z] 19:49:04 ERROR - REFTEST ERROR | REFTEST TEST-UNEXPECTED-FAIL | file:///Users/cltbld/tasks/task_1603395997/build/tests/reftest/tests/docshell/base/crashtests/1257730-1.html | [CONTENT] flushWindow failed: TypeError: can't access property "windowUtils", win is null
[task 2020-10-22T19:49:04.680Z] 19:49:04 ERROR -
[task 2020-10-22T19:49:04.683Z] 19:49:04 INFO - REFTEST TEST-PASS | docshell/base/crashtests/1257730-1.html | (LOAD ONLY)
[task 2020-10-22T19:49:04.684Z] 19:49:04 INFO - REFTEST TEST-END | docshell/base/crashtests/1257730-1.html

Flags: needinfo?(kmaglione+bmo)
Priority: P3 → P2

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:kmag, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(kmaglione+bmo)
Pushed by
Return null from `.contentWindow` when inner window is inactive. r=nika
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

== Change summary for alert #27616 (as of Thu, 12 Nov 2020 16:27:51 GMT) ==


Ratio Suite Test Platform Options Absolute values (old vs new)
2% Base Content JS macosx1014-64-shippable-qr 2,798,629.33 -> 2,841,002.67

For up to date results, see:

You need to log in before you can comment on or make changes to this bug.