1478596 - [JavaScript Error: "TypeError: doc is null" {file: "resource:///actors/ContextMenuChild.sys.mjs" line: 559}]

Status: ASSIGNED

(Firefox :: Menus, defect, P3)

Description

[Rob Wu [:robwu]]

"TypeError: doc is null" has occurred more than a couple of times in tests at
https://searchfox.org/mozilla-central/rev/943a6cf31a96eb439db8f241ab4df25c14003bb8/browser/modules/ContextMenu.jsm#478,485

This error message suggests that aEvent.composedTarget.ownerDocument is null.

Examples of intermittents:
Bug 1433892 : 21 May - 25 July, mostly Linux (once on Windows).

Last known message in https://bugzilla.mozilla.org/show_bug.cgi?id=1433892#c8 is at
https://searchfox.org/mozilla-central/source/browser/components/extensions/test/browser/head.js#261,267,269
The caller is:
https://searchfox.org/mozilla-central/rev/943a6cf31a96eb439db8f241ab4df25c14003bb8/browser/components/extensions/test/browser/browser_ext_menus_events.js#291
I guess that the test timed out because the next method opens a menu (in an extension popup, which has its own <browser> FYI) and waits for it to be shown (which does not happen because of the aforementioned error):
https://searchfox.org/mozilla-central/rev/943a6cf31a96eb439db8f241ab4df25c14003bb8/browser/components/extensions/test/browser/head.js#287-290


Bug 1470940 : 25 June - 10 July (infrequent)
Test times out under similar circumstances (with identical error): https://searchfox.org/mozilla-central/rev/943a6cf31a96eb439db8f241ab4df25c14003bb8/browser/base/content/test/general/browser_bug417483.js#20-23

Comment 1

[Rob Wu [:robwu]]

> This error message suggests that aEvent.composedTarget.ownerDocument is null.

ownerDocument can be null if the node itself is a document. So if aEvent.composedTarget is a document, then this error would occur. I can't rule out this possibility by looking at the code at https://searchfox.org/mozilla-central/rev/943a6cf31a96eb439db8f241ab4df25c14003bb8/dom/events/Event.cpp#282-294

The failures started happening on 21 May: https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?startday=2018-05-1&endday=2018-07-26&tree=all&bug=1433892
That is about two weeks after the related code was last changed in bug 1441647.

Olli, could your change have caused this error? Would the error go away if you add a fall back to aEvent.target.ownerDocument:

let doc = aEvent.composedTarget.ownerDocument || aEvent.target.ownerDocument;

If not sure, then you could land such a change and see if the failure of bug 1433892 goes away. This intermittent happens multiple times a week, so not observing an intermittent for (say) a week could be an indication that the bug has been fixed.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

I guess that it possible, if the event is targeted on, hmm, scrollbar or something, which is native anonymous.

Comment 3

[Rob Wu [:robwu]]

Error message changed due to the file move in https://hg.mozilla.org/mozilla-central/rev/4ec3a9d01b24.

Updating summary to the latest error, e.g. as seen in https://bugzilla.mozilla.org/show_bug.cgi?id=1433892#c22
https://treeherder.mozilla.org/logviewer.html#?job_id=196014945&repo=mozilla-central&lineNumber=3033

Comment 4

[Luca Greco [:rpl] [:luca] [:lgreco]]

As I just mentioned in Bug 1484789 comment 29, this issue seems to be happening in tests that are using (through BrowserTestUtils.synthesizeMouse*) DOMWindowUtils.sendMouseEvent to trigger the context menu mouse event in a newly created remote browser (but I doubt that the issue is specific to the context menu event).

As described in Bug 1519808 comment 0, two calls to DOMWindowUtils.sendMouseEvent with the same parameters (in particular the left and top that should point to the expected DOM element) seems to have different outcomes from time to time (and it seems to be some kind of race, because an arbitrary delay between the remote browser creation and the DOMWindowUtils.sendMouseEvent call seems to be able to reduce the issue).

Comment 5

[Oriol Brufau [:Oriol]]

This is not just intermittent, can be triggered with 100% reliability if you edit devtools/client/jsonview/test/browser.ini to remove

skip-if =
  (os == 'linux' && !swgl) # bug 1720898

And then browser_jsonview_save_json.js fails in treeherder in linux (locally it passes for me).

Example: https://treeherder.mozilla.org/jobs?revision=f7c85f8174029853d35bd00b8165e8892286d802&repo=try

Comment 6

[Shane Caraveo (:mixedpuppy)]

The test failure in bug 1682681 is due to synthesizemouse on the center of an element, and the center of the element is not visible. Restructuring the test html file to avoid that issue.

Comment 7

[Rob Wu [:robwu]]

Observed failure in bug 1775563, e.g. https://treeherder.mozilla.org/logviewer?job_id=419063159&repo=try&lineNumber=6029

Relevant log file pasted at https://bugzilla.mozilla.org/show_bug.cgi?id=1775563#c41

(also, updating title to adjust for the renamed file.)

Comment 8

[Rob Wu [:robwu]]

After fixing an intermittent failure, the bug got re-opened due to a "new" intermittent failure: https://bugzilla.mozilla.org/show_bug.cgi?id=1847216#c47
That failure is caused by this bug.

Since the problem has been ongoing for six years and stays under the radar because the blame goes to the test timeouts, I'll add some logging to make it easier to debug this issue next time it occurs.

Comment 9

[Rob Wu [:robwu]]

Attachment: Bug 1478596 - Add test-only logging to debug "doc is null" error in ContextMenuChild

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf54488baa94
Add test-only logging to debug "doc is null" error in ContextMenuChild r=smaug

Comment 11

[Iulian Moraru]

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