1485157 - browser.xhtml: "document.activeElement is null" in various mochitests

Status: RESOLVED FIXED

(Firefox :: General, defect, P3)

Description

[Brian Grinstead [:bgrins]]

With `mk_add_options 'export MOZ_BROWSER_XHTML=1'`:

./mach mochitest browser/base/content/test/general/browser_unknownContentType_title.js

Leads to a bunch of errors like:

```
FAIL uncaught exception - TypeError: document.activeElement is null at _adjustFocusBeforeTabSwitch@chrome://browser/content/tabbrowser.js:1110:9
updateDisplay@resource:///modules/AsyncTabSwitcher.jsm:416:7
postActions@resource:///modules/AsyncTabSwitcher.jsm:619:5
queueUnload@resource:///modules/AsyncTabSwitcher.jsm:1023:5
requestTab@resource:///modules/AsyncTabSwitcher.jsm:1012:5
updateCurrentBrowser@chrome://browser/content/tabbrowser.js:889:29
_setupEventListeners/<@chrome://browser/content/tabbrowser.js:4362:9
set_selectedIndex@chrome://global/content/bindings/tabbox.xml:610:13
set_selectedPanel@chrome://global/content/bindings/tabbox.xml:629:13
set_selectedIndex@chrome://global/content/bindings/tabbox.xml:383:15
set_selectedItem@chrome://global/content/bindings/tabbox.xml:408:34
set_selectedTab@chrome://global/content/bindings/tabbox.xml:97:15
set selectedTab@chrome://browser/content/tabbrowser.js:273:5
@chrome://mochitests/content/browser/browser/base/content/test/general/browser_unknownContentType_title.js:18:36
Async*Tester_execTest/<@chrome://mochikit/content/browser-test.js:1106:34
async*Tester_execTest@chrome://mochikit/content/browser-test.js:1097:16
nextTest/<@chrome://mochikit/content/browser-test.js:999:9
SimpleTest.waitForFocus/waitForFocusInner/focusedOrLoaded/<@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:795:59
```

It's referring to `document.activeElement.blur()` at https://searchfox.org/mozilla-central/rev/3fa761ade83ed0b8ab463acb057c2cf0b104689e/browser/base/content/tabbrowser.js#1110.

It seems reasonable to null check document.activeElement (and it fixes the test), but we should also figure out why it's different.
We should figure out why activeElement is null here

Comment 1

[Brian Grinstead [:bgrins]]

Here's a trace of this happening:

_adjustFocusBeforeTabSwitch chrome://browser/content/tabbrowser.js:1098:7
updateDisplay resource:///modules/AsyncTabSwitcher.jsm:416:7
postActions resource:///modules/AsyncTabSwitcher.jsm:619:5
queueUnload resource:///modules/AsyncTabSwitcher.jsm:1023:5
requestTab resource:///modules/AsyncTabSwitcher.jsm:1012:5
updateCurrentBrowser chrome://browser/content/tabbrowser.js:889:29
_setupEventListeners/< chrome://browser/content/tabbrowser.js:4374:9
set_selectedIndex chrome://global/content/bindings/tabbox.xml:597:13
set_selectedPanel chrome://global/content/bindings/tabbox.xml:616:13
set_selectedIndex chrome://global/content/bindings/tabbox.xml:374:15
set_selectedItem chrome://global/content/bindings/tabbox.xml:399:34
_selectNewTab chrome://global/content/bindings/tabbox.xml:444:11
onxblmousedown chrome://global/content/bindings/tabbox.xml:704:11

It can be reproduced by opening a new tab then closing it with the keyboard shortcut (URL bar becomes unfocused)

Comment 2

[Brian Grinstead [:bgrins]]

Attachment: browser-xul.gif

Doing some additional logging for focusout event and _adjustFocusBeforeTabSwitch with browser.xul vs browser.xhtml

Comment 3

[Brian Grinstead [:bgrins]]

Attachment: browser-xhtml.gif

Comment 4

[Brian Grinstead [:bgrins]]

I think this is due to some difference in document.activeElement between HTML and XUL documents:

- When entering _adjustFocusAfterTabSwitch in browser.xhtml document.activeElement is typically null, unless if the URL bar is focused, in which case it is the html:input.autocomplete-textbox.urlbar-input.textbox-input.
- When entering that function in browser.xul then a <browser> is the activeElement if the URL bar isn't focused, and the html:input is the activeElement if the URL bar is focused.

From https://developer.mozilla.org/en-US/docs/Web/API/DocumentOrShadowRoot/activeElement:

> Often activeElement will return an <input> or <textarea> object if it has the text selection at the time.  If so, you can get
> more detail by using the element's selectionStart and selectionEnd properties.  Other times the focused element might be a 
> <select> element (menu) or an <input> element, of type "button", "checkbox", or "radio".

> When there is no selection, the active element is the page's <body> or null.

Comment 5

[Brian Grinstead [:bgrins]]

Looking through nsGlobalWindowOuter::SetFocusedElement: https://searchfox.org/mozilla-central/search?q=symbol:_ZN19nsGlobalWindowOuter17SetFocusedElementEPN7mozilla3dom7ElementEjb%2C_ZN18nsPIDOMWindowOuter17SetFocusedElementEPN7mozilla3dom7ElementEjb&redirect=false.

One thing that stands out is that we have special handling for retargetdocumentfocus attribute (which is set to urlbar in browser.xul): https://searchfox.org/mozilla-central/rev/2fe43133dbc774dda668d4597174d73e3969181a/dom/base/nsFocusManager.cpp#4043-4058.

Comment 6

[Brian Grinstead [:bgrins]]

Attachment: Bug 1485157 - Check to make sure document.activeElement exists before attempting to blur it;r=Gijs

We're ending up in a case here where document.activeElement is null in
browser.xhtml but it's a <browser> tag in browser.xul.

We'll need more analysis and testing to decide if we want the HTML or XUL
activeElement behavior, and then adjust as needed. But in the meantime,
this unbreaks a bunch of browser.xhtml tests and is a safe null check in
both cases.

Comment 7

[:Gijs (he/him)]

Comment on attachment 9005275 [details]
Bug 1485157 - Check to make sure document.activeElement exists before attempting to blur it;r=Gijs

:Gijs (he/him) has approved the revision.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/098f6aaf5241
Check to make sure document.activeElement exists before attempting to blur it;r=Gijs

Comment 9

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/098f6aaf5241