Closed Bug 710143 Opened 8 years ago Closed 8 years ago

Investigate why we fail add-ons manager tests with "Modal dialog has been found and processed" on the Mozmill side

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: vladmaniac, Assigned: vladmaniac)

References

Details

(Whiteboard: [mozmill-test-failure][mozmill-aom])

Attachments

(1 file)

We are failing almost all add-ons manager restart tests with 

TimeoutError("Modal dialog has been found and processed")@resource://mozmill/modules/utils.js:429 waitFor([object Proxy],"Modal dialog has been found and processed",25000,100,[object Proxy])@resource://mozmill/modules/utils.js:467 

We have reproduced sometimes manually this, therefore we have bug 702266 for that. 
This bug is intended to track investigation of this failure on the Mozmill side

Please do not dupe this, since it's a general tracking bug
Blocks: 709932, 708387, 701893
Assignee: nobody → vlad.mozbugs
Status: NEW → ASSIGNED
Blocks: 702266
Which branches and platforms are affected? I don't think it's only Linux as given in the OS field. I really miss this information in the initial comment.
(In reply to Henrik Skupin (:whimboo) from comment #1)
> Which branches and platforms are affected? I don't think it's only Linux as
> given in the OS field. I really miss this information in the initial comment.

Sorry for missing this important detail - all platforms are affected
OS: Linux → All
Hardware: x86 → All
So when has this been started exactly?
I believe it's been happening intermittently with various add-ons manager tests since we started developing them over a quarter ago. I'll let Vlad confirm that though.
(In reply to Henrik Skupin (:whimboo) from comment #3)
> So when has this been started exactly?

From the moment we started testing add-on installation 

We are not failing modal dialog handling on other tests, so I tend to think our API is ok - the failure for add-on installation tests are caused by the hang of the download progress bar see bug 702266
Which means we are running into a timeout in the test, continue with the next one, and sometimes later the add-on installation dialog comes up? Hm, that would be messy.

Dave, is there a back-end API to cancel a running download/installation?
(In reply to Henrik Skupin (:whimboo) from comment #6)
> Which means we are running into a timeout in the test, continue with the
> next one, and sometimes later the add-on installation dialog comes up? Hm,
> that would be messy.
> 
> Dave, is there a back-end API to cancel a running download/installation?

You can call AddonManager.getAllInstalls and call cancel on each one. I think in this case that might still cause a doorhanger to appear telling the user the download was cancelled.
That would be totally ok. The only thing we should not end-up with for the time being is a non-handled modal dialog window.

Vlad, can you please check the proposal from Dave and how we can get this implemented? If not, I will have a look at hopefully next week.
I also seem to encounter this issue in tests from testSearch where we have the Manage Search Engines modal-dialog. Tested on beta, nightly and release.
Remus, this is different and has to be filed as a separate bug. Please concentrate on add-on related tests here.
Sorry, this was a false alarm coming from a timeout in a waitFor call.
Henrik or Vlad, is there a status update here? It's been over a month since the last meaningful comment.
Whiteboard: [mozmill-test-failure][mozmill-aom]
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #12)
> Henrik or Vlad, is there a status update here? It's been over a month since
> the last meaningful comment.

As I've stated in the meeting wiki noted I've backlogged this bug for the moment because I'm out of ideas for it..I can't think of a possible fix on the mozmill side.
Vlad, not sure what you are talking about but have you checked the feedback from Dave in comment 7? I never got a reply from you based on this proposal.
(In reply to Henrik Skupin (:whimboo) from comment #14)
> Vlad, not sure what you are talking about but have you checked the feedback
> from Dave in comment 7? I never got a reply from you based on this proposal.

Why do I want to cancel a download/install? I did not understand that part
This would be helpful for teardown, so that we can ensure that no more download is in progress which would raise the installation dialog and block the UI.
Attached patch wip patch1Splinter Review
Used testInstallTheme and update TIMEOUT in addons.js because I get 

"Selected category has been loaded." Timeout error in addonsManager.open() - this fixes it. 

Now every time the install dialog freezes, we cancel the install in teardown module
Attachment #593748 - Flags: feedback?(hskupin)
Comment on attachment 593748 [details] [diff] [review]
wip patch1

>+++ b/tests/functional/restartTests/testAddons_installTheme/test1.js
> 
>+Components.utils.import("resource://gre/modules/AddonManager.jsm");
[..]
>+function teardownModule() {
>+  AddonManager.getAllInstalls(function (aInstalls) {
>+    if (aInstalls.length == 1) {
>+      aInstalls[0].cancel();

Patch looks fine. But please don't check if it equals to 1. Instead we want to cancel all installation requests which are in the queue.

Also this code has to land in the addons.js module, where it can be used by any of our tests which attempt to install add-ons. Feel free to create a new bug under shared modules.

>-// Bug 701893 - Failure in testAddons_installTheme/test1.js
>-setupModule.__force_skip__ = "Bug 701893 - Failure in " + 
>-                             "testAddons_installTheme/test1.js";
>-teardownModule.__force_skip__ = "Bug 701893 - Failure in " + 
>-                                "testAddons_installTheme/test1.js";

I wouldn't unskip the test yet because it will still fail with the installation, or does a timeout of 7000ms change that?
Attachment #593748 - Flags: feedback?(hskupin) → feedback+
Thanks for feedback - this was a WIP to see if I properly understood what we want and I use the backend API stuff properly. The rest will be addressed in a further patch. 

the new timeout is enough for the test to pass. tested against mac and linux.
Depends on: 723470
I'm thinking on passing this code to a shared module function under bug 723470 in which we also need to handle the behavior when we actually cancel an install (new modal dialog for e.g)
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #20)
> I'm thinking on passing this code to a shared module function under bug
> 723470 in which we also need to handle the behavior when we actually cancel
> an install (new modal dialog for e.g)

Sounds fine to me. Any code which can benefit multiple tests *should* go into the Shared Modules anyway, in my opinion.
Right now we are concentrating on re-enabling addons manager tests which failed with this error some time ago. We are working on the failure bugs themselves (dependencies here)

Not sure what updates would be necessary for this bug report but I think we will not have any patches here. Should we close it?
I think that we are ok now and don't have to do any more investigation. Please concentrate on enabling skipped tests.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.