Closed Bug 524830 Opened 15 years ago Closed 15 years ago

[mozmill] Test script for Close Downloads Dialog test case

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: u279076, Assigned: u279076)

Details

Attachments

(1 file, 1 obsolete file)

This is a placeholder bug for creating a Mozmill test script for the "Close Downloads Dialog" Litmus test case.

1.9.1: https://litmus.mozilla.org/show_test.cgi?id=5937
1.9.2: https://litmus.mozilla.org/show_test.cgi?id=7980
I believe this functionality is also tested in bug 518369.

var testOpenDownloadManager = function()
{
  var dm = new DownloadsAPI.downloadManager();

  // Use the main menu
  dm.open(controller, false);
  dm.close();

  // Use the keyboard shortcuts
  dm.open(controller, true);
  dm.close();
}

If I am correct, the above code gives us validation of both opening and closing the Downloads dialog.

Whimboo, please advise.
My patch on bug 518369 only uses Cmd+W to close the download manager and doesn't handle the given testcase in detail. Even I don't know if we would have to make it ready for localization. So my idea is:

* Change the downloadManager class to use VK_ESCAPE to close the window
* Create a new test for closing the download manager with the optional ways (which will only be a switch between ESC and Cmd+W, clicking the X we shouldn't be able to)
* Get the shortcut for 'W' from the properties file (if it's inside a DTD add this bug to the dependency of the DTD implementation bug)
Looking into localization of the W key, I came across http://dxr.proximity.on.ca/dxr/mozilla-central/dom/interfaces/events/nsIDOMKeyEvent.idl.html

Is it possible we could use these macros for all future key bindings in Mozmill?
What do you mean with macros? The given url lists all possible keys we have available for usage. There is no macro definition. Or do you ask if we should use VK_ all the time? We shouldn't do that. Only special keys should be called that way.
(In reply to comment #4)
> What do you mean with macros? The given url lists all possible keys we have
> available for usage. There is no macro definition. 
Sorry, I used the wrong terminology here.

> Or do you ask if we should
> use VK_ all the time? We shouldn't do that. Only special keys should be called
> that way.
Ok, good enough for me. Anyway, test is coming shortly in the pipeline.  This test will implement CTRL/CMD+W and ESC.  I've placed comments at the end of the test method to indicate test cases we need to consider in the future (once bug 525060 is resolved).  I'll probably file a new bug to track "extension" of this test script.
While the shared module can always use ESC to close the download manager you can test CMD/Ctrl+W especially in this test. It's the only time we really have to test for it.
So this test depends on functionality being provided in 3 seperate bugs:

Bug 525060 - System Level Dialogs
Bug 531211 - Broken ALT+F4
Bug 504635 - Extraction from DTD/Property List (l10n)

I would argue, for the purposes of a BFT, we should not block checking in a test script on any of these bugs.  There are scenarios which work and we can always extend the test script later.
Attached patch Initial Patch (obsolete) — Splinter Review
Here is my initial patch.  There's quite a few tests in the script that do not work or have not been coded yet.  We decided to push them off until the FFT as the BFT states to close the dialog by any means (it does not specify methods for closing the dialog).

As a result, this test tests:
ESC
ACCEL+J (Windows + Mac)
ACCEL+SHIFT+Y (Linux)
ACCEL+W


l10n:
A quick note about l10n.  W, J, and Y commands are defined in downloads.dtd#35.
http://mxr.mozilla.org/l10n-central/search?string=cmd.close.commandKey&find=downloads.dtd
http://mxr.mozilla.org/l10n-central/search?string=cmd.close2.commandKey&find=downloads.dtd
http://mxr.mozilla.org/l10n-central/search?string=cmd.close2Unix.commandKey&find=downloads.dtd
This test uses hardcoded values for W, J, and Y.  For the time being, this seems to be safe as all locales are using the same character.  Once bug 504635 is resolved, we can make this test even safer by calling the ENTITY value.

ALT+F4:
This test is coded but commented out due to bug 531211.  We'll fix it in time for the FFT.

The following scenarios were not coded due to bug 525060.  They too can wait until the FFT.
Alt+Space (Windows and Linux)
Linux Program Submenu > Close
   * Right click program item in panel
   * Right click title bar
   * Click o button on the left side of the title bar
Mac Red Orb in the titlebar
Windows X button in the titlebar

I'm going to file a new bug for the FFT and set up the dependencies.  None of this should affect the BFT test script.
Attachment #414889 - Flags: review?(hskupin)
Status: NEW → ASSIGNED
I was thinking about this patch a lot the last days. All parts related to our BFT test are fine. The only concern I have with the remaining tests we could do. At the moment I don't think that those shouldn't be done against the Download Manager. Instead these are steps which relate to any open window. That's why I think we should remove those lines and do not file a new bug on it.

If you are ok with it and update the patch can you also please add the Litmus meta data at the end of the file. See my latest post on the mozmill-dev list.
In other words, remove the commented code, add the metadata and submit a new patch?  I'm not completely clear what lines you want me to change...
Right. That's what I want to see. For the Litmus meta data part see all test files in the repository. I have updated them completely. Add the function at the bottom and remove the comment under the license plate.
Attached patch Rev1Splinter Review
Suggested revisions made.  I've tested this on Linux and Windows XP and it works.  Please test on Mac prior to check-in.

Thanks.
Attachment #414889 - Attachment is obsolete: true
Attachment #418659 - Flags: review?(hskupin)
Attachment #414889 - Flags: review?(hskupin)
Comment on attachment 418659 [details] [diff] [review]
Rev1

Looks and works great.

>+testCloseDownloadManager.meta = {litmusids : [5937,7980]};

Next time please only add the id of the 1.9.2 branch testcase. I will query the id for 1.9.1 in the spreadsheet. That will make the test more branch stable.
Attachment #418659 - Flags: review?(hskupin) → review+
I had to do a little tweak here. While running a negative test I discovered that for both Download Manager tests we have now the dialog stays open. I have added a teardownModule function to catch such a situation.

Landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/53e0f755dcab
http://hg.mozilla.org/qa/mozmill-tests/rev/5361828343bd
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Mass move of Mozmill Test related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Component: Download Manager → Mozmill Tests
Product: Toolkit → Mozilla QA
QA Contact: download.manager → mozmill-tests
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: