727961 - [SeaMonkey] "test_destinationURI_annotation.xul | Test timed out."

Status: RESOLVED WONTFIX

(Toolkit :: Downloads API, defect, P5)

Description

[Serge Gautherie (:sgautherie)]

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1329215161.1329219819.16122.gz
WINNT 5.2 comm-central-trunk debug test mochitest-other on 2012/02/14 02:26:01
+
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Aurora/1329290562.1329294861.20808.gz
OS X 10.5 comm-aurora debug test mochitest-other on 2012/02/14 23:22:42
+
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Beta/1329292009.1329295621.21868.gz
OS X 10.6 comm-beta debug test mochitest-other on 2012/02/14 23:46:49
{
33373 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/toolkit/mozapps/downloads/tests/chrome/test_destinationURI_annotation.xul | Test timed out.
}

Opt build on local Windows 2000:
this test hangs after opening a "Enter name of file to save to..." + "unknownContentType_dialog_layout_data.pif" dialog.

Guessing: this test assumes something about "History" which is not implemented in SeaMonkey.

Comment 1

[Alex Keybl [:akeybl]]

This is an issue with test cases run on SM, so no need to track from our end. Sending over to Felipe to take a look when he gets the chance.

Comment 2

[:Felipe Gomes (needinfo for replies!)]

Hi Serge: this test landed a few months ago. Did this failure begin recently or has it been there since the test landed?

I don't think it has anything to do with history. The test opens the unknownContentType dialog and tries to call confirm() on it. So a best guess is that something is going wrong with that.
IIRC, SM has a different DM. Do you know if the URL for the unknown content dialog in SM would also be "chrome://mozapps/content/downloads/unknownContentType.xul"?

Comment 3

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) Add a wanted todo() when skipping test on Windows lower than 7

Not this bug, but noticed while testing locally.

Comment 4

[:Felipe Gomes (needinfo for replies!)]

For this actual bug, I think we should just skip this code in Seamonkey, as this is testing a feature built for the upcoming new DM in Firefox which will be different from Seamonkey. Serge, what do you think?

Comment 5

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 598412 [details] [diff] [review]
(Av1) Add a wanted todo() when skipping test on Windows lower than 7

The best here would be to have a is(true, ...) rather than a _todo_ since there's nothing missing to be done on this test

Comment 6

[Serge Gautherie (:sgautherie)]

["Mid-air collision detected!": anyway...]

(In reply to Felipe Gomes (:felipe) from comment #2)

> Hi Serge: this test landed a few months ago. Did this failure begin recently
> or has it been there since the test landed?

Likely the later, as this bug affects all 3 branches.

> I don't think it has anything to do with history. The test opens the
> unknownContentType dialog and tries to call confirm() on it. So a best guess
> is that something is going wrong with that.
> IIRC, SM has a different DM. Do you know if the URL for the unknown content
> dialog in SM would also be
> "chrome://mozapps/content/downloads/unknownContentType.xul"?

That URL works on SeaMonkey and test_unknownContentType_dialog_layout.xul passes.

1st idea:

I wonder whether test_destinationURI_annotation.xul depends on Toolkit UI and would need
{
  let dmui = getDMUI();
  if (!dmui) {
    todo(false, "skip test for toolkit download manager UI");
    return;
  }
}

Fwiw, test_taskbarprogress_service.xul and test_retention_is_0_closes.xul are two 2 other tests which don't have this check.
But I don't know whether they would need it either.

2nd idea:

Actually, the test does open UCT_URI, "accept" it then closes it, as expected.
Then it hangs on that new "Enter name of file to save to..." dialog.
If I click on its 'Save' button, then the test passes (with 5 checks).

Maybe setting some preference is needed to show some DMUI instead?

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to Felipe Gomes (:felipe) from comment #4)
> For this actual bug, I think we should just skip this code in Seamonkey, as
> this is testing a feature built for the upcoming new DM in Firefox which
> will be different from Seamonkey. Serge, what do you think?

My 1st idea, then.
NB: I don't know much about DM/UI(s), so I can give hints only.


(In reply to Felipe Gomes (:felipe) from comment #5)
> The best here would be to have a is(true, ...) rather than a _todo_ since
> there's nothing missing to be done on this test

I know, though I'm used to use todo() in such cases too:
it doesn't mean "developer needed" but "don't assume in-test checks succeeded" :-|

Comment 8

[:Felipe Gomes (needinfo for replies!)]

(In reply to Serge Gautherie (:sgautherie) from comment #6)
> Actually, the test does open UCT_URI, "accept" it then closes it, as
> expected.
> Then it hangs on that new "Enter name of file to save to..." dialog.
> If I click on its 'Save' button, then the test passes (with 5 checks).

Ok thanks, so that's where the difference is. The test is meant to specifically test the case where the File dialog does not come up (i.e., when only Save and Cancel is provided). See here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/tests/chrome/test_destinationURI_annotation.xul#27
Does this classify as depending on the Toolkit UI behavior?

Comment 9

[Serge Gautherie (:sgautherie)]

(In reply to Felipe Gomes (:felipe) from comment #8)

> Ok thanks, so that's where the difference is. The test is meant to
> specifically test the case where the File dialog does not come up (i.e.,
> when only Save and Cancel is provided). See here:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/
> tests/chrome/test_destinationURI_annotation.xul#27

That "simple UI" is 'unknownContentType.xul', right?
And the "File dialog" is the next/added dialog that shows up in SeaMonkey?
I don't know where showing (or not) the File dialog is handled.

> Does this classify as depending on the Toolkit UI behavior?

Maybe KaiRo can help.

Comment 10

[Robert Kaiser]

(In reply to Serge Gautherie (:sgautherie) from comment #9)
> I don't know where showing (or not) the File dialog is handled.

Could be download manager code but not sure, no time to dig into the details of the test or the code.

> > Does this classify as depending on the Toolkit UI behavior?
> 
> Maybe KaiRo can help.

From what I read here (and as I said, no time to dig into the guts of this atm), it might be that the UI has something to do with it here, but OTOH, this might be behavior that should be implemented but is missing on our side, so even if it is, it might be something we should fix in our code. But that's all just guessing, sorry for not having the time to go into the depths of this.

Comment 11

[Mark Banner (:standard8)]

This test seems to have been removed now.