Closed Bug 1009460 Opened 10 years ago Closed 6 years ago

Add automated test to verify the UI and preferences after forgetting the email for unverified user

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

38 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mihaelav, Unassigned)

References

()

Details

Attachments

(1 file, 6 obsolete files)

Precondition: Have a Firefox account for which the email was not verified.

Steps:

1. Go to Preferences > Sync and click the "Forget this Email" link

2. Verify that the UI is disconnected and shows no information regarding the disconnected account:
>> * about:accounts page shows "Get started" button
>> * The email address of the account is no longer displayed in the Panel Menu
>> * Panel menu shows "Sign in to Sync" option
>> * Preferences > Sync panel shows: "Create Account", "Sign In" and "Using an older version of Sync" links
>> * Preferences > Sync shows no information regarding the disconnected Firefox account:
>>    - email address not displayed
>>    - "Disconnect..." button and "Manage" link not present
>>    - device name not displayed
>>    - none of the what to sync options (Tabs, Bookmarks, Passwords, History, Add-ons, Preferences) displayed
>>    - "Terms of service" and "Privacy Notice" links not displayed
Component: Firefox Sync: Backend → Firefox Sync: UI
I take this.
Assignee: nobody → cosmin.malutan
(In reply to Mihaela Velimiroviciu [QA] (:mihaelav) from comment #0)
> Precondition: Have a Firefox account for which the email was not verified.
Since we never verify this address I think we could use a single account for this since it would be out of the scope of bug to create a new account for each time we ran this specific test.
const TEST_ACCOUNT = { 'username': 'unconfirmed_account@restmail.net', 'password': 'test' };

> 2. Verify that the UI is disconnected and shows no information regarding the
> disconnected account:
> >> * about:accounts page shows "Get started" button
> >> * The email address of the account is no longer displayed in the Panel Menu
> >> * Panel menu shows "Sign in to Sync" option
> >> * Preferences > Sync panel shows: "Create Account", "Sign In" and "Using an older version of Sync" links
> >> * Preferences > Sync shows no information regarding the disconnected Firefox account:
> >>    - email address not displayed
> >>    - "Disconnect..." button and "Manage" link not present
> >>    - device name not displayed
> >>    - none of the what to sync options (Tabs, Bookmarks, Passwords, History, Add-ons, Preferences) displayed
> >>    - "Terms of service" and "Privacy Notice" links not displayed
Those steps are a little bit more complex and we would need an UI class if we want this to look nice, otherwise we could just get elements in test.
Also I think since we have a new UI for preferences (about:preferences) I suggest we would implement this directly for the new UI and we won't need library for handling modal dialogs in tps tests for a moment. 

Henrik if this approach sounds good for you I will get started on this.
Flags: needinfo?(hskupin)
(In reply to Cosmin Malutan from comment #2)
> Since we never verify this address I think we could use a single account for
> this since it would be out of the scope of bug to create a new account for
> each time we ran this specific test.
> const TEST_ACCOUNT = { 'username': 'unconfirmed_account@restmail.net',
> 'password': 'test' };

Well, I don't understand the steps. For what is step 1 used? How can I forget about a login when I never logged in before? I think this is obsolete. Please clarify the steps first.

> Those steps are a little bit more complex and we would need an UI class if
> we want this to look nice, otherwise we could just get elements in test.
> Also I think since we have a new UI for preferences (about:preferences) I
> suggest we would implement this directly for the new UI and we won't need
> library for handling modal dialogs in tps tests for a moment. 

Sounds good but keep in mind that those settings are only active for Firefox 32.0a1. So we won't be able to backport the test to older versions of Firefox. What we might do is to set the preferences before the test.
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #3)
> (In reply to Cosmin Malutan from comment #2)
> > Since we never verify this address I think we could use a single account for
> > this since it would be out of the scope of bug to create a new account for
> > each time we ran this specific test.
> > const TEST_ACCOUNT = { 'username': 'unconfirmed_account@restmail.net',
> > 'password': 'test' };
> 
> Well, I don't understand the steps. For what is step 1 used? How can I
> forget about a login when I never logged in before? I think this is
> obsolete. Please clarify the steps first.
You have to log in with an unverified account so steps 1 and 2 to make sense. If you Log-in with an unverified account, go to Preferences > Sync  and there you'll have an "Forget this Email" link. This will act similar to an log-out.
So you are trying to create an account then. You do not log-in, because that's only possible once the email address has been verified. And as long as you haven't done this, there is no ui change here, which we should test. Really, I don't understand this testcase.
You can log-in with an account that hasn't been confirmed, on an unverified account we have a "Forget this Email" link and a "Verify Email" button, and with a verified account we have "Manage" and "Disconnect". I guess this is the purpose of this test to check the an unverified account has a different UI.
So please update the test so we can make sure the right things are getting tested. Also I would prefer to hear feedback on it from Edwin, before we actually get the implementation started.
For this test we need an unverified ff account, we would test the new UI so we have to set browser.preferences.inContent to True in test, and we need a shared UI library to use it in our tests.

Steps: 
1 * Log-in with an unverified account.
2 * Check and click "Forget this Email" link
3 * Check the UI to see that is disconnected:
    - about:accounts page shows "Get started" button
    - The email address of the account is no longer displayed in the Panel Menu
    - Panel menu shows "Sign in to Sync" option
    - Preferences > Sync panel shows: "Create Account", "Sign In" and "Using an older version of Sync" links
    - Preferences > Sync shows no information regarding the disconnected Firefox account

Edwin are those steps correct, and also how many UI checks would sufficience after we disconnect? All from step 3?
Flags: needinfo?(edwong)
(In reply to Cosmin Malutan from comment #8)

Just two more question, because I thought it was clear that at least 1) will be addressed in the updated steps:

> 1 * Log-in with an unverified account.

Where is the step to create that account?

> 2 * Check and click "Forget this Email" link

If we want to test the ui, why don't we test things, while the user is logged in?
(In reply to Henrik Skupin (:whimboo) from comment #9)
> > 1 * Log-in with an unverified account.
> 
> Where is the step to create that account?
We will use this account only to log-in, not to sync so we can use a single account across all testruns. We can create this account manually and use it as a constant, for example TEST_ACCOUNT = { 'username': 'unconfirmed_account@restmail.net', 'password': 'test_account' };
(In reply to Cosmin Malutan from comment #8)
> Edwin are those steps correct, and also how many UI checks would sufficience
> after we disconnect? All from step 3?

The steps look correct.  In terms of the items to validate, whatever number is reasonable: 1 or 2 UI items.

I'm fine with the most efficient way you want to organize the tests, in running multiple interactions and validation of state..
Flags: needinfo?(edwong)
Mentor: hskupin
Whiteboard: [mentor=whimboo][lang=js] → [lang=js]
Blocks: 1035848
No longer blocks: 1007559
Attached patch patch v1.0 (obsolete) — Splinter Review
Here is the patch with the tests it depends on Mihaela patch from bug 1009441.
Attachment #8462539 - Flags: review?(andrei.eftimie)
Attachment #8462539 - Flags: review?(andreea.matei)
Comment on attachment 8462539 [details] [diff] [review]
patch v1.0

Review of attachment 8462539 [details] [diff] [review]:
-----------------------------------------------------------------

::: services/sync/tests/lib/syncUI.js
@@ +77,5 @@
> +      case "createAccountLink":
> +        return [findElement.Selector(root, '#noFxaAccount label.text-link:nth-child(2)')];
> +
> +      case "logInLink":
> +        return [findElement.Selector(root, '#noFxaAccount label.text-link:nth-child(3)')];

These selectors are nasty, but we don't have any 'proper' selectors for them.
We should file a bug to get either an id or a className for each of them, the current approach is brittle.

::: services/sync/tests/tps/mozmill_1009460_unverified.js
@@ +7,5 @@
> +var SyncUI = require("../lib/syncUI");
> +var utils = require("../lib/utils");
> +
> +const TEST_ACCOUNT = {
> +  'username': 'unconfirmed_account@restmail.net',

I don't like this. With public credentials anyone could compromise this test by logging into this account and verifying the email. Or deleting the account.
We should be able to create an account first. Since we don't need to verify the email, it should be doable in a single test.

@@ +11,5 @@
> +  'username': 'unconfirmed_account@restmail.net',
> +  'password': 'test_account'
> +};
> +
> +var setupModule = function(module) {

Please use `function setupModule`

@@ +18,5 @@
> +  module.aboutAccounts = new SyncUI.AboutAccountsPage(module.controller);
> +  module.syncPrefs = new SyncUI.SyncPreferences(module.controller);
> +}
> +
> +var testTestStep = function() {

Same here. function name()

@@ +30,5 @@
> +  // Click on forget account link
> +  syncPrefs.getElement({type: "forgetLink"}).click();
> +
> +  // Check that account has been disconnected
> +  assert.waitFor(function () {

Please use the fat arrow function syntax.

@@ +33,5 @@
> +  // Check that account has been disconnected
> +  assert.waitFor(function () {
> +    let createAccountLink = syncPrefs.getElement({type: "createAccountLink"})
> +    return utils.isDisplayed(controller, createAccountLink);
> +  }, "'Create Account' link has been diplayed");

is displayed
Attachment #8462539 - Flags: review?(andrei.eftimie)
Attachment #8462539 - Flags: review?(andreea.matei)
Attachment #8462539 - Flags: review-
Attached patch patch v1.1 (obsolete) — Splinter Review
(In reply to Andrei Eftimie from comment #13)
> ::: services/sync/tests/lib/syncUI.js
> 
> ::: services/sync/tests/tps/mozmill_1009460_unverified.js
> @@ +7,5 @@
> > +var SyncUI = require("../lib/syncUI");
> > +var utils = require("../lib/utils");
> > +
> > +const TEST_ACCOUNT = {
> > +  'username': 'unconfirmed_account@restmail.net',
> 
> I don't like this. With public credentials anyone could compromise this test
> by logging into this account and verifying the email. Or deleting the
> account.
> We should be able to create an account first. Since we don't need to verify
> the email, it should be doable in a single test.
I don't like it neither, but it's simplest implementation for this test. For creating the account, and removing it in teardown we would have to create a library, we have to create and remove email accounts so we don't spam the service. All of this are error prone and will require a lot of work, and all of this for testing the unverified link in a "better" way. Also if an error will rise in the process of creating the account, the test will also fail and the account should be removed in the teardown, so we will be unable to check if something was wrong with the account. 
I would rather keep it like this, if the test will fail, we will be able to check the account really simple considering that it's public. In case it will be verified by a human error, we will be able to delete the account and recreate it, so no change in repository will be necessary.
Attachment #8462539 - Attachment is obsolete: true
Attachment #8475858 - Flags: review?(andrei.eftimie)
Comment on attachment 8475858 [details] [diff] [review]
patch v1.1

Review of attachment 8475858 [details] [diff] [review]:
-----------------------------------------------------------------

Henrik, there's an inline comment about how we should proceed with an unverified account that I would like you input to.
Thanks.

::: services/sync/tests/lib/syncUI.js
@@ +78,5 @@
>        case "manageLink":
>          return [findElement.Selector(root, '#fxaLoginStatus label.text-link')];
>  
> +      case "forgetLink":
> +        return [findElement.Selector(root, '#fxaLoginStatus label.text-link:nth-child(2)')];

You would get the same result with the query: 
'#fxaLoginStatus .text-link', as there's only one "link" there.

@@ +81,5 @@
> +      case "forgetLink":
> +        return [findElement.Selector(root, '#fxaLoginStatus label.text-link:nth-child(2)')];
> +
> +      case "createAccountLink":
> +        return [findElement.Selector(root, '#noFxaAccount label.text-link:nth-child(2)')];

Not a huge fan of nth-of-child for this and the following selectors, but there's nothing else to base them on.

We should file a bug against Pref > Sync UI to add some classes to these elements so we can properly select them.

::: services/sync/tests/tps/mozmill_1009460_unverified.js
@@ +1,5 @@
> +/* This Source Code Form is subject to the terms of the Mozilla Public
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +Cu.import('resource://tps/auth/fxaccounts.jsm');

You've used both double and single quotes interchangeably in this file.
Please update all of the to be the same type: double (as other TPS tests I've checked all use double quotes)

@@ +7,5 @@
> +var SyncUI = require("../lib/syncUI");
> +var utils = require("../lib/utils");
> +
> +const TEST_ACCOUNT = {
> +  'username': 'unconfirmed_account@restmail.net',

I still can't endorse this.

Henrik, please advise on how to proceed here.
Are we ok with a predefined unverified account?
I feel this might lead to unwanted failures down the road. (Anyone could delete the account, or "verify" it and our tests would unexpectedly fail.

I'm not sure about the alternative. We will need to use fxa-accounts, so this might not be a pure JS test.

@@ +11,5 @@
> +  'username': 'unconfirmed_account@restmail.net',
> +  'password': 'test_account'
> +};
> +
> +function setupModule(module) {

nit: aModule please

@@ +18,5 @@
> +  module.aboutAccounts = new SyncUI.AboutAccountsPage(module.controller);
> +  module.syncPrefs = new SyncUI.SyncPreferences(module.controller);
> +}
> +
> +function testTestStep() {

Can we give this a better name?
"testTestStep" doesn't tell anything

@@ +27,5 @@
> +  assert.equal(syncPrefs.getEmailAddress(), TEST_ACCOUNT['username'],
> +               "Correct email account is displayed");
> +
> +  // Click on forget account link
> +  syncPrefs.getElement({type: "forgetLink"}).click();

There's a possibility that this isn't yet visible.
The whole Preferences UI is build similar to a one-page webapp, so most content is available in the DOM, but is not visible when not loaded. So the query might return the correct node, but the click might miss if it's not in a visible state.
Attachment #8475858 - Flags: review?(andrei.eftimie)
Attachment #8475858 - Flags: review-
Attachment #8475858 - Flags: feedback?(hskupin)
Comment on attachment 8475858 [details] [diff] [review]
patch v1.1

Review of attachment 8475858 [details] [diff] [review]:
-----------------------------------------------------------------

A needinfo request would have been the better solution here for a faster feedback. Anyway, please find my answer inline. f+ given that the test seems to do what it should do, but I didn't check this in detail yet.

::: services/sync/tests/lib/syncUI.js
@@ +81,5 @@
> +      case "forgetLink":
> +        return [findElement.Selector(root, '#fxaLoginStatus label.text-link:nth-child(2)')];
> +
> +      case "createAccountLink":
> +        return [findElement.Selector(root, '#noFxaAccount label.text-link:nth-child(2)')];

Has a bug been filed meanwhile for an enhancement?

::: services/sync/tests/tps/mozmill_1009460_unverified.js
@@ +7,5 @@
> +var SyncUI = require("../lib/syncUI");
> +var utils = require("../lib/utils");
> +
> +const TEST_ACCOUNT = {
> +  'username': 'unconfirmed_account@restmail.net',

First we cannot use such an account name. It would have to start at least with `tps_`. In regards the question about verification I'm not sure how long restmail.net will keep the verification email in the inbox. I think you can easily delete this email. But people may be able to re-ask for such an email. So not trivial indeed.

I think that our testers won't abuse that, and in case of any automated solution there is less benefit for people. I don't think that we will have a problem with that. I would suggest we go ahead for now, and in the very unlikely case it will happen, we can decide what to do. Maybe we could lock this account server-side to a specific state.
Attachment #8475858 - Flags: feedback?(hskupin) → feedback+
Attached patch patch v1.2 (obsolete) — Splinter Review
> > +      case "forgetLink":
> > +        return [findElement.Selector(root, '#fxaLoginStatus label.text-link:nth-child(2)')];
> > +
> > +      case "createAccountLink":
> > +        return [findElement.Selector(root, '#noFxaAccount label.text-link:nth-child(2)')];
> 
> Has a bug been filed meanwhile for an enhancement?
Those changes have been already done in bug 1016300.
In this patch I just updated the locators due to enhancement.
Thanks for feedback henrik, this is still blocked by bug 1009441, beside that I'll say the implementation is done here.
Attachment #8493084 - Flags: review?(hskupin)
(In reply to Cosmin Malutan from comment #17)
> Those changes have been already done in bug 1016300.

That's not the bug you wanted to refer to, right?
Why not? This bug added IDs for labels: rejectUnlinkFxaAccount, verifyFxaAccount and unverifiedUnlinkFxaAccount. Sow we don't have to file a bug for that anymore.
Ah, misread. So good to hear that they fixed that themselves.
Comment on attachment 8493084 [details] [diff] [review]
patch v1.2

Review of attachment 8493084 [details] [diff] [review]:
-----------------------------------------------------------------

This patch needs a rewrite once the dependent modules have been landed. But here for now my review feedback...

::: services/sync/tests/tps/mozmill_1009460_unverified.js
@@ +20,5 @@
> +}
> +
> +function testTestStep() {
> +  Authentication.signIn({"username": TEST_ACCOUNT['username'],
> +                         "password": TEST_ACCOUNT['password']});

Ideally this is setup code and not part of the test. There is also no check like waitForSetupComplete() here. Where do we make sure the user is logged in?

@@ +27,5 @@
> +  assert.equal(syncPrefs.getEmailAddress(), TEST_ACCOUNT['username'],
> +               "Correct email account is displayed");
> +
> +  // Click on forget account link
> +  syncPrefs.getElement({type: "forgetLink"}).click();

As we practice forever declare the variable and then trigger the action.

@@ +31,5 @@
> +  syncPrefs.getElement({type: "forgetLink"}).click();
> +
> +  // Check that account has been disconnected
> +  assert.waitFor(() => {
> +    let createAccountLink = syncPrefs.getElement({type: "createAccountLink"})

I don't see the need why we have to retrieve the element in each iteration. Is that lazily created?

@@ +36,5 @@
> +    return utils.isDisplayed(controller, createAccountLink);
> +  }, "'Create Account' link is displayed");
> +
> +  assert.waitFor(() => {
> +    let logInLink = syncPrefs.getElement({type: "logInLink"})

Same here.
Attachment #8493084 - Flags: review?(hskupin) → review-
Attached patch patch v2.0 (obsolete) — Splinter Review
(In reply to Henrik Skupin (:whimboo) from comment #21)
> This patch needs a rewrite once the dependent modules have been landed. But
> here for now my review feedback...
I'll do that once the dependent modules will be landed.
> ::: services/sync/tests/tps/mozmill_1009460_unverified.js
> @@ +20,5 @@
> > +}
> > +
> > +function testTestStep() {
> > +  Authentication.signIn({"username": TEST_ACCOUNT['username'],
> > +                         "password": TEST_ACCOUNT['password']});
> 
> Ideally this is setup code and not part of the test. There is also no check
> like waitForSetupComplete() here. Where do we make sure the user is logged
> in?
I think this has to be part of the test, in setup we login with an verified account. Regarding the waiting, this is handled by the TPS framework.
 
> > +    let createAccountLink = syncPrefs.getElement({type: "createAccountLink"})
> 
> I don't see the need why we have to retrieve the element in each iteration.
> Is that lazily created?
It's not lazily created it might been at the time I started to work on patch as they changed a lot since then.
I moved it outside of wait-for condition.
Attachment #8475858 - Attachment is obsolete: true
Attachment #8493084 - Attachment is obsolete: true
Whiteboard: [lang=js] → [lang=js][sprint]
Depends on: 1079736
No longer depends on: 1009441
Status: NEW → ASSIGNED
This doesn't need to sync anything so I don't think it's suitable to automated it with TPS but with mozmill.
Henrik what do you think?
Sounds valid to me. No need to use TPS if we can handle it with a Mozmill test directly.
Okey then, we will do this using mozmill.
No longer blocks: 1035848
Component: Firefox Sync: UI → Mozmill Tests
No longer depends on: 1079736
Product: Mozilla Services → Mozilla QA
QA Contact: hskupin
Version: unspecified → Firefox 38
Attached patch patch v1.0 (obsolete) — Splinter Review
I remade the whole patch, as we decided to do this with mozmill. I had to add another entry in the lib/getElements.

I restricted this test to ran only on nightly, because it runs against the real server and we won't want to highload the server when we ran 100 beta or release jobs.
https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#backoff-protocol

Report:
http://mozmill-crowd.blargon7.com/#/remote/report/52e1dd05f3d97380e39f88e69c4ec389
Attachment #8498797 - Attachment is obsolete: true
Attachment #8554532 - Flags: review?(mihaela.velimiroviciu)
Attachment #8554532 - Flags: review?(andreea.matei)
Attachment #8554532 - Flags: feedback?(hskupin)
Comment on attachment 8554532 [details] [diff] [review]
patch v1.0

Review of attachment 8554532 [details] [diff] [review]:
-----------------------------------------------------------------

You missed to check some things after forgetting the email.

::: firefox/tests/remote/testPreferences/testForgetUnverifiedAccount.js
@@ +2,5 @@
> + * License, v. 2.0. If a copy of the MPL was not distributed with this
> + * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +"use strict";
> +var utils = require("../../../../lib/utils");

You need a blank line before this

@@ +70,5 @@
> +  var deck = aboutPreferences.getElement({type: "sync_weavePrefsDeck"});
> +  assert.waitFor(() => deck.getNode().selectedPanel.id === "noFxaAccount",
> +                 "'No Firefox account' panel is displayed");
> +
> +  aboutPreferences.close();

You should also check that the UI is reset in the other places which are related:
* The about:accounts page shows "Get started" button (instead of "Manage")
* The panel menu shows "Sign in to Sync" button, not the email address of the account which was "forgotten"
Attachment #8554532 - Flags: review?(mihaela.velimiroviciu)
Attachment #8554532 - Flags: review?(andreea.matei)
Attachment #8554532 - Flags: review-
Attached patch 1009460.patch (obsolete) — Splinter Review
Form comment 11 I understood it will sufficience 1-2 UI elements, I added the rests now. 

http://mozmill-crowd.blargon7.com/#/remote/report/6b1e6b9bf618fb20da2bf8727440d456
Attachment #8554532 - Attachment is obsolete: true
Attachment #8554532 - Flags: feedback?(hskupin)
Attachment #8555072 - Flags: review?(mihaela.velimiroviciu)
Attachment #8555072 - Flags: review?(andreea.matei)
Attachment #8555072 - Flags: feedback?(hskupin)
Comment on attachment 8555072 [details] [diff] [review]
1009460.patch

Review of attachment 8555072 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks Cosmin for adding those checks, I think it's good to verify the different UI areas involved in this scenario.
Attachment #8555072 - Flags: review?(mihaela.velimiroviciu) → review+
Comment on attachment 8555072 [details] [diff] [review]
1009460.patch

Review of attachment 8555072 [details] [diff] [review]:
-----------------------------------------------------------------

Small nits.

::: firefox/tests/remote/testPreferences/testForgetUnverifiedAccount.js
@@ +21,5 @@
> +  aModule.menuPanel = aModule.browserWindow.navBar.menuPanel;
> +
> +  aModule.browserWindow.tabs.closeAllTabs();
> +
> +    // Run this test only against Nightly

The comment is a bit shifted

@@ +61,5 @@
> +                 "Confirmation email has been sent", TIMEOUT_REMOTE);
> +  aboutAccounts.close();
> +}
> +
> +function testForgetUnverifiedAccount() {

Please add jsdoc

@@ +92,5 @@
> +  var getStarted = aboutAccounts.getElement({type: "getStartedButton"});
> +  assert.ok(utils.isDisplayed(controller, getStarted),
> +            "'Get Started' button is displayed.");
> +
> +  aboutAccounts.close();

Maybe have this in teardownModule too in case we fail?
Attachment #8555072 - Flags: review?(andreea.matei) → review+
Attached patch patch v1.1Splinter Review
(In reply to Andreea Matei [:AndreeaMatei] from comment #30)
> @@ +92,5 @@
> > +  var getStarted = aboutAccounts.getElement({type: "getStartedButton"});
> > +  assert.ok(utils.isDisplayed(controller, getStarted),
> > +            "'Get Started' button is displayed.");
> > +
> > +  aboutAccounts.close();
> 
> Maybe have this in teardownModule too in case we fail?
We close all tabs in the teardown, that will close this even if we fail, no need to add extra references in module scope.
Attachment #8555072 - Attachment is obsolete: true
Attachment #8555072 - Flags: feedback?(hskupin)
Attachment #8557058 - Flags: review?(hskupin)
This is in a  final state, most probably It won't get landed today since it didn't get a review in the past 2 weeks, so I will unassigned, it's free to take.
Assignee: cosmin.malutan → nobody
Status: ASSIGNED → NEW
Comment on attachment 8557058 [details] [diff] [review]
patch v1.1

Review of attachment 8557058 [details] [diff] [review]:
-----------------------------------------------------------------

We are not going to add new Mozmill tests to our repository. If that is an important test for QE please get it converted to Marionette.
Attachment #8557058 - Flags: review?(hskupin)
Mentor: hskupin
Whiteboard: [lang=js][sprint]
Mozmill is dead, WONTFIX the remaining bugs.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: