1236036 - test_alerts.html is failing when run inside a docker image

Status: RESOLVED FIXED

(Firefox :: Shell Integration, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

in working on getting our unittests running on linux64 inside a docker image, test_alerts.html consistently fails.  I can reproduce it locally inside the docker image, and likewise can see it pass successfully on my local linux64 machine.

All of the other tests in the alerts/ directory pass just fine, it is just the test_alerts.html which fail.  As far as I can tell, this is the only one that uses a synchronous callback.  When running locally in docker, I launch vnc and watch the browser start, then a notification appears, but the test just sits there after the notifications disappears.  If I intervene and open up the error console, then the test passes right away.

I am not familiar with this test or how the integration works with the shell.  We are still making sure the image is correct, and this is something that could be an issue with the OS vs an issue with the test.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

please needinfo :bz on Jan 4 when he is accepting needinfo? requests again

Comment 2

[Lina Butler [:lina]]

Hmm, interesting. Out of curiosity, which distro and window manager are you using? I wonder if it's using the libnotify backend to show the alerts...

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

we are running ubuntu-12.04 (attempting to match the same version we have on our existing ec2 vms).  The window manager we have is gnome-session || gnome-shell; both are showing the same problem.  I verified we have libnotify-bin and notify-osd installed on the system.

If there is a part of window manager, process, dbus, package, etc. I would be happy to install that.

Comment 4

[Joel Maher ( :jmaher ) (UTC -8)]

:bz, I see your name on the test itself, who would be the right person to help figure out why this specific test case is timing out on our docker containers?

Comment 5

[Boris Zbarsky [:bzbarsky]]

We're talking about toolkit/components/alerts/test/test_alerts.html ?  I have never seen this test before.  I don't have either blame or review blame for any of the changesets that ever touched this file...  Are you sure you have the right "bz"?

The original test was written by Michael Ventnor and reviewed by roc.  But really the question is who knows something about the alerts service on Linux.

I assume that you're not getting the "alertfinished" notification, right?  Are you getting the "alertshow" observer notification?  If so, then look up the blame on the code that normally dispatches "alertfinished" and poke them as a start?

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

thanks :bz, sorry for bothering you and I have a place to start hunting!

Comment 7

[Joel Maher ( :jmaher ) (UTC -8)]

it seems that test_alerts.html tests for synchronous alerts where as other tests in the same directory cover different aspects of the alerting service (it exists, async alerts, etc.)

From the code, it seems as though we receive the alertshow message in the observer, but we don't get the alertfinished.  Once I clicked on an alert (to detect if I could receive a message for it), the display of future alerts changed (not a bubble, but a simple unstyled rectangle) and the test passed!

:kitcambridge, can you help me figure out what is going on with this specific test case?  I assume it is something with libnotify, dbus, or some odd behavior.

Comment 8

[Lina Butler [:lina]]

Sorry for the delay, Joel. I wonder if the test is running into the same issue as OS X. If you're running GNOME shell with libnotify, the alert might be persisted in the notification center, and `alertfinished` may not be triggered until it's closed.

Could you please try removing the conditional around https://dxr.mozilla.org/mozilla-central/rev/878033e3ca98726f11dd3a30b0768961d221d22a/toolkit/components/alerts/test/test_alerts.html#68-73, so that the test calls `notifier.closeAlert(alertName)` unconditionally? I don't have an Ubuntu VM set up on my laptop, but I can investigate more next week, too.

Comment 9

[Joel Maher ( :jmaher ) (UTC -8)]

Kit!  this worked.  This is GNOME (launching gnome-session with .xsessionrc) and using libnotify (I verified it is the latest for ubuntu 12.04 and works with notify-send and some dbus listeners.

When looking at it in person, I see the alert disappear when it is supposed to, now it seems that the test passes really fast.  We can make this change to the test, but maybe your opinion on if we are getting proper coverage would be good to sanity check.

Comment 10

[Lina Butler [:lina]]

Attachment: MozReview Request: Bug 1236036 - Automatically close native notifications in test_alerts.html. r?MattN

Review commit: https://reviewboard.mozilla.org/r/31043/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/31043/

Comment 11

[Lina Butler [:lina]]

Thanks, Joel! I think the fix is to call `closeAlert` if we're on a platform that supports native notifications. Does the attached patch work for you?

Comment 12

[Joel Maher ( :jmaher ) (UTC -8)]

yes, this works for me locally on my docker instance

Comment 13

[Matthew N. [:MattN]]

Comment on attachment 8708407 [details]
MozReview Request: Bug 1236036 - Automatically close native notifications in test_alerts.html. r?MattN

https://reviewboard.mozilla.org/r/31043/#review27907

Comment 14

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/3a496a28e22f

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3a496a28e22f

Comment 16

[Armen [:armenzg]]

Attachment: Output from running test_alerts.html under docker with e10s enabled

It seems that this test fails in *e10s* under docker (bug 1246019)

Should I re-open this bug? and dupe against it?

Here are the steps to reproduce:
https://pastebin.mozilla.org/8859022

I can see the notification show up and it then dissapears, however, the test does not finish.

Comment 17

[Armen [:armenzg]]

Here's a screenshot of some messages under the browser console:
http://people.mozilla.org/~armenzg/sattap/4b640eb6.png

I doubt they're useful but just in case.

I also tried commenting out the patch that was landed on comment 14 and nothing changed.

Comment 18

[Lina Butler [:lina]]

* Could you try commenting out the `if` around `closeAlert`, so that it's called unconditionally? (I'm guessing this won't help, if the Docker setup is the same as for non-e10s, but let's try it just in case).

* Could you please upload a screenshot of the notification?

Thanks!

Comment 19

[Armen [:armenzg]]

Here's the screenshot:
http://people.mozilla.org/~armenzg/sattap/33f89ffb.png

I tried commenting out that if block [1] without anything changing.

The alert goes away in both cases.

Ftr, the steps to reproduce are accurate.
You will have to run this and adjust --device to match appropiately (this command is only needed once after a reboot of your machine):
> sudo modprobe v4l2loopback 

To install it for the first time you would need this:
> sudo apt-get install v4l2loopback-dkms

https://hg.mozilla.org/integration/fx-team/rev/3a496a28e22f#l1.16

Comment 20

[Lina Butler [:lina]]

Cool, thanks for doing that! I'll take a look on my Linux machine later today.

Comment 21

[Joel Maher ( :jmaher ) (UTC -8)]

armen, can you try reproducing this failure with --interactive?  that would be the big win!

Comment 22

[Lina Butler [:lina]]

The problem is that the Docker environment uses native libnotify notifications, but we don't support closing them yet. Once that's fixed, the test should pass. Right now, it just throws an exception.

I considered disabling this test entirely for non-XUL alerts (or just silencing the exception with a `todo`), but decided against it. This seems to be one of the few tests that actually exercises the system alerts backend. :-)

Thanks again for your awesome instructions, :armenzg! I had to make two small changes:

* Add `-P` to `docker run`, so that it publishes all exposed ports. Without that, I couldn't VNC in, even though the container exposes 5900.
* `export MOZ_SANDBOX_UNEXPECTED_THREADS=1` before running the test. Otherwise, it tripped this assertion: https://dxr.mozilla.org/mozilla-central/rev/584870f1cbc5d060a57e147ce249f736956e2b62/security/sandbox/linux/common/SandboxInfo.cpp#158

Comment 23

[Mayur Patil]

[bugday-20160323]

Status: RESOLVED,FIXED -> UNVERIFIED

Comments:
STR: Not clear.
Developer specific testing

Component: 
Name			Firefox
Version			46.0b9
Build ID		20160322075646
Update Channel          beta
User Agent		Mozilla/5.0 (Windows NT 6.1; WOW64; rv:46.0) Gecko/20100101 Firefox/46.0
OS			Windows 7 SP1 x86_64

Expected Results: 
Developer specific testing

Actual Results: 
As expected

Comment 24

[Joel Maher ( :jmaher ) (UTC -8)]

this is verified, when we fixed the bug and the test started passing.