Closed
Bug 710143
Opened 14 years ago
Closed 13 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)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: vladmaniac, Assigned: vladmaniac)
References
Details
(Whiteboard: [mozmill-test-failure][mozmill-aom])
Attachments
(1 file)
4.57 KB,
patch
|
whimboo
:
feedback+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Updated•14 years ago
|
Assignee: nobody → vlad.mozbugs
Status: NEW → ASSIGNED
Comment 1•14 years ago
|
||
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.
Assignee | ||
Comment 2•14 years ago
|
||
(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
Comment 3•14 years ago
|
||
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.
Assignee | ||
Comment 5•14 years ago
|
||
(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
Comment 6•14 years ago
|
||
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?
Comment 7•14 years ago
|
||
(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.
Comment 8•14 years ago
|
||
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.
Comment 9•14 years ago
|
||
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.
Comment 10•14 years ago
|
||
Remus, this is different and has to be filed as a separate bug. Please concentrate on add-on related tests here.
Comment 11•14 years ago
|
||
Sorry, this was a false alarm coming from a timeout in a waitFor call.
Comment 12•13 years ago
|
||
Henrik or Vlad, is there a status update here? It's been over a month since the last meaningful comment.
Assignee | ||
Comment 13•13 years ago
|
||
(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.
Comment 14•13 years ago
|
||
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.
Assignee | ||
Comment 15•13 years ago
|
||
(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
Comment 16•13 years ago
|
||
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.
Assignee | ||
Comment 17•13 years ago
|
||
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 18•13 years ago
|
||
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+
Assignee | ||
Comment 19•13 years ago
|
||
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.
Assignee | ||
Comment 20•13 years ago
|
||
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)
Comment 21•13 years ago
|
||
(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.
Assignee | ||
Comment 22•13 years ago
|
||
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?
Comment 23•13 years ago
|
||
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: 13 years ago
Resolution: --- → WORKSFORME
Updated•6 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•