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

Comment 12

[Rob Wu [:robwu]]

(In reply to Rob Wu [:robwu] from comment #1)

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

With the extra logging, I've confirmed that this is the case. I checked a handful of logs across different bugs, and all logs look like this:

doc is unexpectedly null (bug 1478596), composedTarget=[object HTMLDocument]
 Alternative: target=[object HTMLDocument] and its doc=null
 Alternative: originalTarget=[object HTMLDocument] and its doc=null
 Alternative: explicitOriginalTarget=[object HTMLDocument] and its doc=null
JavaScript error: resource:///actors/ContextMenuChild.sys.mjs, line 559: TypeError: doc is null

Interestingly, all different target fields point to the HTML doc as being the target.

Would the error go away if you add a fall back to aEvent.target.ownerDocument:

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

The error would not go away, because ownerDocument of a document is null, as the logs show.

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #2)

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

I think that this theory is increasingly likely. Knowing that this happens doesn't fix the bug though.

To find a potential solution, we could log the x,y offsets of the click, the dimensions of the document, and whether there are other viable alternatives such as document.elementsFromPoint(x,y).

Comment 13

[Oriol Brufau [:Oriol]]

Would this work?

let target = aEvent.composedTarget;
let doc = target.nodeType == Node.DOCUMENT_NODE ? target : target.ownerDocument;

Comment 14

[Rob Wu [:robwu]]

(In reply to Oriol Brufau [:Oriol] from comment #13)

Would this work?

let target = aEvent.composedTarget;
let doc = target.nodeType == Node.DOCUMENT_NODE ? target : target.ownerDocument;

This would get rid of the error, but I'm not sure if it would result in meaningful behavior. The intent of tests is often to open a context menu on a specific target (e.g. link in page). Triggering the context menu on the document could result in confusing behavior.

Comment 15

[BugBot [:suhaib / :marco]]

The leave-open keyword is there and there is no activity for 6 months.
:robwu, maybe it's time to close this bug?
For more information, please visit BugBot documentation.

Comment 16

[Vincent Hilla [:vhilla]]

I can reproduce this failure consistently on Linux opt builds with the patch from Bug 543435 on browser_pocket_panel.js (see Bug 1781272), only in headless mode. But it is sensitive to small changes in timing.

Comment 17

[Vincent Hilla [:vhilla]]

pernosco trace

Comment 18

[Vincent Hilla [:vhilla]]

I resolved the issue with that test, the pocket panel wasn't readily loaded when the click was synthesized.

Comment 19

[:Gijs (he/him)]

The fix from Florian in bug 1970802 (to BrowserTestUtils to wait for a reflow in the parent process which should cause updated layout info for the viewport to be posted to the child) I think will get rid of most of the remainder of the failures here? Though not sure how best to check that that is the case.