1657182 - Intermittent browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | Test timed out -

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Treeherder Bug Filer]

Filed by: btara [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=312019645&repo=autoland
Full log: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/O1gRmXiORcCICFLAtVshLQ/runs/0/artifacts/public/logs/live_backing.log

---

...
[task 2020-08-04T17:16:55.929Z] 17:16:55     INFO - Entering test bound testActivationMousedown
[task 2020-08-04T17:16:55.929Z] 17:16:55     INFO - Waiting for focus on gMainButton1
[task 2020-08-04T17:16:55.929Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | gMainButton1 focused after ArrowDown pressed - 
[task 2020-08-04T17:16:55.929Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | mousedown activated after space - 
[task 2020-08-04T17:16:55.929Z] 17:16:55     INFO - Leaving test bound testActivationMousedown
[task 2020-08-04T17:16:55.930Z] 17:16:55     INFO - Entering test bound testTabArrowsBrowser
[task 2020-08-04T17:16:55.930Z] 17:16:55     INFO - Console message: [JavaScript Error: "The character encoding of the HTML document was not declared. The document will render with garbled text in some browser configurations if the document contains characters from outside the US-ASCII range. The character encoding of the page must be declared in the document or in the transfer protocol." {file: "data:text/html,<textarea id="docTextarea">value</textarea><button id="docButton"></button>" line: 0}]
[task 2020-08-04T17:16:55.930Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | Embedded doc has correct URl - 
[task 2020-08-04T17:16:55.930Z] 17:16:55     INFO - Waiting for focus on docBack
[task 2020-08-04T17:16:55.930Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | docBack focused after Tab pressed - 
[task 2020-08-04T17:16:55.931Z] 17:16:55     INFO - Waiting for focus on doc
[task 2020-08-04T17:16:55.931Z] 17:16:55     INFO - Buffered messages logged at 17:15:29
[task 2020-08-04T17:16:55.931Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | doc focused after Tab pressed - 
[task 2020-08-04T17:16:55.931Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | textarea focused - 
[task 2020-08-04T17:16:55.934Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | selectionStart initially 0 - 
[task 2020-08-04T17:16:55.934Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | selectionStart 1 after ArrowRight - 
[task 2020-08-04T17:16:55.934Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | selectionStart 0 after ArrowLeft - 
[task 2020-08-04T17:16:55.934Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | textarea still focused - 
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Waiting for focus on docButton
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Waiting for focus on docBack
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - TEST-PASS | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | docButton focused after Tab pressed - 
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Leaving test bound testTabArrowsBrowser
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Entering test bound testTabArrowsIframe
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Buffered messages logged at 17:15:30
[task 2020-08-04T17:16:55.935Z] 17:16:55     INFO - Embedded doc readyState interactive, location data:text/html,<textarea id="docTextarea">value</textarea><button id="docButton"></button>
[task 2020-08-04T17:16:55.936Z] 17:16:55     INFO - Waiting for load on embedder
[task 2020-08-04T17:16:55.936Z] 17:16:55     INFO - Buffered messages finished
[task 2020-08-04T17:16:55.941Z] 17:16:55     INFO - TEST-UNEXPECTED-FAIL | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | Test timed out - 
[task 2020-08-04T17:16:55.942Z] 17:16:55     INFO - GECKO(1493) | [Parent 1493, Main Thread] WARNING: '!inner', file /builds/worker/checkouts/gecko/dom/ipc/jsactor/JSWindowActorProtocol.cpp, line 172
[task 2020-08-04T17:16:55.942Z] 17:16:55     INFO - GECKO(1493) | [Parent 1493, Main Thread] WARNING: '!inner', file /builds/worker/checkouts/gecko/dom/ipc/jsactor/JSWindowActorProtocol.cpp, line 172
[task 2020-08-04T17:16:55.943Z] 17:16:55     INFO - GECKO(1493) | MEMORY STAT | vsize 7924MB | residentFast 526MB | heapAllocated 116MB
[task 2020-08-04T17:16:55.943Z] 17:16:55     INFO - TEST-OK | browser/components/customizableui/test/browser_PanelMultiView_keyboard.js | took 90196ms

Comment 1

[James Teh [:Jamie]]

This is ridiculous. The document shows a readyState of interactive, yet a load event never gets fired on the iframe. If this were a remote iframe, I might be able to understand that; the load event could theoretically fire in parallel. In this case (non-remote), I don't see how that's possible.

Gijs, any idea what's going on here? I think I've exhausted all the solutions I can think of.

I guess the textarea should still be present even if it's interactive, so we could allow both interactive and ready and not wait for the load event in that case. However, I'm afraid we'll just end up with a timeout for the loading state if we do that.

Comment 2

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #1)

This is ridiculous. The document shows a readyState of interactive, yet a load event never gets fired on the iframe. If this were a remote iframe, I might be able to understand that; the load event could theoretically fire in parallel. In this case (non-remote), I don't see how that's possible.

Gijs, any idea what's going on here? I think I've exhausted all the solutions I can think of.

For a browser element that isn't remote (which I think this isn't?), I would expect that you'd be able to capture the "load" event firing directly from the browser element, using a capturing event listener, ie BrowserTestUtils.waitForEvent(aEmbedder, "load", true). Does that not work?

I guess the textarea should still be present even if it's interactive, so we could allow both interactive and ready and not wait for the load event in that case. However, I'm afraid we'll just end up with a timeout for the loading state if we do that.

If there's no paint yet it might not be focusable which might impact the test?

Comment 3

[James Teh [:Jamie]]

(In reply to :Gijs (he/him) from comment #2)

For a browser element that isn't remote (which I think this isn't?),

In this case, we're dealing with a non-remote iframe (not a browser) inside a panelview. I'm not sure how this is implemented internally, but there's no xul:browser in the DOM for this case. I'm already waiting for the load event on the iframe (aEmbedder). I'm not using a capturing event listener here, but I don't think I should need to do that, since iframes are supposed to get load events fired on them.

Comment 4

[:Gijs (he/him)]

(In reply to James Teh [:Jamie] from comment #3)

(In reply to :Gijs (he/him) from comment #2)

For a browser element that isn't remote (which I think this isn't?),

In this case, we're dealing with a non-remote iframe (not a browser) inside a panelview. I'm not sure how this is implemented internally, but there's no xul:browser in the DOM for this case. I'm already waiting for the load event on the iframe (aEmbedder). I'm not using a capturing event listener here, but I don't think I should need to do that, since iframes are supposed to get load events fired on them.

Yeah, I don't know then. Nika, any idea what we're missing here? Why would a load event not fire on a parent-process (same-process) iframe, if when inspecting the doc it has readyState: interactive? If it's relevant, the doc in question is from a data: URI.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

It appears as though we intentionally don't fire the "load" event for <iframe> elements into typeChrome windows: https://searchfox.org/mozilla-central/rev/a315a1a0f09550e23e4590a77e74f36543315da3/dom/base/nsGlobalWindowInner.cpp#1947-1952. That behaviour is only performed in content windows.

I'm guessing based on these being XUL <iframe> elements, that we're performing this load in a chrome docshell in the parent process, which would explain why we're not dispatching the load event like you're expecting.

You'll probably have better luck using a web progress listener in this particular situation.

Comment 6

[James Teh [:Jamie]]

Thanks Nika. I think I managed to prove that a capturing load listener on the iframe also works; i.e. it captured the load event from the document.

In the browser console, I did this:

n = document.getElementById("nav-bar");
ifr = document.createXULElement("iframe");
ifr.setAttribute("src", "about:support");
ifr.addEventListener("load", () => alert('hi'), true);
setTimeout(() => n.append(ifr), 3000);

After 3 seconds, the alert appeared. With a normal event listener instead of a capturing listener, the alert didn't appear.

This is a bit different to the test because I couldn't get a data URL to work in the browser console, even with security.allow_unsafe_parent_loads set to true. Hopefully, that doesn't impact the results.

So, we're back to Gijs's suggestion in comment 2, with slightly different reasoning. :)

Comment 7

[James Teh [:Jamie]]

Using the same browser toolbox console test, a capturing event listener on a browser element also seems to capture the load. So, we should be able to handle both with the same code this way.

Comment 8

[James Teh [:Jamie]]

Attachment: Bug 1657182: browser_PanelMultiView_keyboard.js: Use a capturing event listener on the browser/iframe to capture the load event from the child document.

Comment 9

[Intermittent Failures Robot]

5 failures in 4618 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 4
• mozilla-central: 1

Platform breakdown:

• macosx1014-64: 2
• linux1804-64: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1657182&startday=2020-08-03&endday=2020-08-09&tree=all

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2666ab7c289e
browser_PanelMultiView_keyboard.js: Use a capturing event listener on the browser/iframe to capture the load event from the child document. r=Gijs

Comment 11

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/2666ab7c289e

Comment 12

[Intermittent Failures Robot]

3 failures in 3601 pushes (0.001 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• autoland: 3

Platform breakdown:

• linux1804-64: 3

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1657182&startday=2020-08-10&endday=2020-08-16&tree=all