Closed Bug 1236036 Opened 5 years ago Closed 5 years ago

test_alerts.html is failing when run inside a docker image

Categories

(Firefox :: Shell Integration, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 46
Tracking Status
firefox46 --- fixed

People

(Reporter: jmaher, Unassigned)

References

Details

Attachments

(2 files)

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.
please needinfo :bz on Jan 4 when he is accepting needinfo? requests again
Flags: needinfo?(jmaher)
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...
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.
Flags: needinfo?(jmaher)
: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?
Flags: needinfo?(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?
Flags: needinfo?(bzbarsky)
thanks :bz, sorry for bothering you and I have a place to start hunting!
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.
Flags: needinfo?(kcambridge)
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.
Flags: needinfo?(kcambridge)
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.
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?
Flags: needinfo?(jmaher)
yes, this works for me locally on my docker instance
Flags: needinfo?(jmaher)
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
Attachment #8708407 - Flags: review?(MattN+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/3a496a28e22f
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
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.
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.
* 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!
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
Cool, thanks for doing that! I'll take a look on my Linux machine later today.
Flags: needinfo?(kcambridge)
armen, can you try reproducing this failure with --interactive?  that would be the big win!
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
Depends on: 1227730
Flags: needinfo?(kcambridge)
No longer depends on: 1227730
[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
this is verified, when we fixed the bug and the test started passing.
You need to log in before you can comment on or make changes to this bug.