TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/content-policy/test-general-content-policy.js | test-general-content-policy.js::test_generalContentPolicy

RESOLVED FIXED in Thunderbird 60.0

Status

defect
RESOLVED FIXED
Last year
Last year

People

(Reporter: jorgk, Assigned: jorgk)

Tracking

Trunk
Thunderbird 60.0

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Assignee

Description

Last year
TEST-UNEXPECTED-FAIL | /builds/slave/test/build/tests/mozmill/content-policy/test-general-content-policy.js | test-general-content-policy.js::test_generalContentPolicy

First seen Fri Feb 16, 2018, 10:58:37
M-C last good: 994a8d6eccbcdc6106794705bd77e3ac5f
M-C first bad: 9eaebbcc33fd3824876db1b8b33750e997

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=994a8d6eccbcdc6106794705bd77e3ac5f&tochange=9eaebbcc33fd3824876db1b8b33750e997

https://public-artifacts.taskcluster.net/av0xaNiiS824epRFaL0Pjg/0/public/logs/live_backing.log
Log says:
INFO -  SUMMARY-UNEXPECTED-FAIL | Z:\task_1518780275\build\tests\mozmill\content-policy\test-general-content-policy.js | test-general-content-policy.js::test_generalContentPolicy
INFO -    EXCEPTION: Ci.nsIDOMHTMLMediaElement is undefined

Surely due to the removal of nsIDOMHTMLMediaElement in bug 1407040.

Boris, we meet again. What's the quick fix for:
https://dxr.mozilla.org/comm-central/rev/961aa136630db53e2f0371e445b5f05e554a573a/mail/test/mozmill/content-policy/test-general-content-policy.js#76
return element.networkState != Ci.nsIDOMHTMLMediaElement.NETWORK_NO_SOURCE;
Hard-code the constant? (3)

Briefly looking through the changesets of bug 1407040 I didn't see a replacement.
Flags: needinfo?(bzbarsky)
Assignee

Comment 1

Last year
Oh, element.networkState != element.NETWORK_NO_SOURCE; should do it.
Assignee

Comment 2

Last year
Having trouble right now running Mozmill locally, but this should do it.
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Flags: needinfo?(bzbarsky)
Attachment #8951601 - Flags: review?(acelists)
Assignee

Comment 3

Last year
Fixed my Mozmill and the test passes with this patch.

Aceman, I saw a few of these:
JavaScript error: resource://mozmill/modules/frame.js -> file:///c:/mozilla-source/comm-central/mail/test/mozmill/shared-modules/test-window-helpers.js, line 1456: TypeError: aWindow is undefined.

Could you take a look at those in a separate bug.

Comment 4

Last year
Comment on attachment 8951601 [details] [diff] [review]
1438825-nsIDOMHTMLMediaElement.patch

Review of attachment 8951601 [details] [diff] [review]:
-----------------------------------------------------------------

Yes, looks like what other similar code in c-c and m-c is doing.
Attachment #8951601 - Flags: review?(acelists) → review+

Comment 5

Last year
(In reply to Jorg K (GMT+1) from comment #3)
> Aceman, I saw a few of these:
> JavaScript error: resource://mozmill/modules/frame.js ->
> file:///c:/mozilla-source/comm-central/mail/test/mozmill/shared-modules/test-
> window-helpers.js, line 1456: TypeError: aWindow is undefined.
Great, that's the new KeyboardEvent code changed in bug 1437269 :( So we need to find out which offender does not pass a window.
>  element.networkState != element.NETWORK_NO_SOURCE; should do it.

That sounds perfect, fwiw.  ;)

> So we need to find out which offender does not pass a window.

A bunch of callsites there used to default aWindow to "window" but that got taken out.  Might help to put it back...

Though I guess that case is event.window coming back undefined, right?  There is no "window" property on events.  There is "view" (which is a Window) on UIEvent...  But also, you could pass the event itself as the thing the for-in loop happens over, no?

Comment 7

Last year
(In reply to Boris Zbarsky [:bz] (no decent commit message means r-) from comment #6)
> A bunch of callsites there used to default aWindow to "window" but that got
> taken out.  Might help to put it back...
> 
> Though I guess that case is event.window coming back undefined, right? 
> There is no "window" property on events.  There is "view" (which is a
> Window) on UIEvent...  But also, you could pass the event itself as the
> thing the for-in loop happens over, no?

Thanks. We filed bug 1438891 for this.
We have several event.window calls that can be found via dxr. Are those different events?
I'd be happy to get the list of keys from the event or just do without a window if possible.

Comment 8

Last year
May event.key be the key name we want?
Assignee

Comment 9

Last year
Was comment #8 meant for bug 1437269? I'll answer it there.

Comment 10

Last year
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/3d60610f1b2e
port bug 1407040: Remove use of nsIDOMHTMLMediaElement. r=aceman
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Assignee

Updated

Last year
Target Milestone: --- → Thunderbird 60.0
Assignee

Updated

Last year
Duplicate of this bug: 1407043
You need to log in before you can comment on or make changes to this bug.