1136661 - Add automated test for installing add-ons in private browsing

Status: NEW

(Firefox :: Private Browsing, defect)

Description

[Mihaela Velimiroviciu (:mihaelav)]

Add automated test for steps 5&7 of the following Moztrap scenario:
https://moztrap.mozilla.org/manage/case/11514/

Steps:
5. Install an add-on from the private window.
 * The add-on gets installed without issues and it works fine in both windows.
7. Close the private window.
* The installed add-on stick in the browser. No private data is kept (history, cache, cookies, browser console etc).

Comment 1

[Mihaela Velimiroviciu (:mihaelav)]

Attachment: v1

Tim, I saw that you added more tests for private browsing, could you please review this one or defer it to someone else if necessary?
Thank you!

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Comment on attachment 8577205 [details] [diff] [review]
v1

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

Hmmm, that test doesn't seem to actually install an add-on and then check the add-on is still around after closing the private window. I'll have to defer to someone else, I don't know anything about our add-on test suites and how to do that best.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Ah, I think the mention of add-ons is a bit of a red-herring here. But it is the most convenient way to run through that moztrap test case, just not relevant to an automated test. I *think* the intent here is to ensure entering customization mode in a private window acts the same as any other window - changes still happen in all windows, and are persisted even when the private window is closed.

Which, incidentally, means step 6's expected result is wrong. Toolbar customizations should apply to all windows.

And this test should probably go in browser/components/customizableui/test

Comment 4

[Mihaela Velimiroviciu (:mihaelav)]

Attachment: v2

Moved the test under customizableui.
Indeed, the expected result from step 6 of the moztrap test is wrong, I let the manual team know in order to update the test.

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 8583112 [details] [diff] [review]
v2

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

::: browser/components/customizableui/test/browser_privatebrowsing_installAddon.js
@@ +1,3 @@
> +/* 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/. */

Test files are expected to default to public-domain these days (see http://blog.gerv.net/2014/09/licensing-policy-change-tests-are-now-public-domain/). Which also means we don't need any license header in tests anymore.

@@ +4,5 @@
> +
> +"use strict";
> +
> +let tmp = {};
> +Cu.import("resource://gre/modules/Promise.jsm", tmp);

Shouldn't need to import this anymore - the native Promise object should already be in scope.

@@ +21,5 @@
> +
> +  let win = window;
> +  let pbWin = yield promiseNewWindowLoaded({private: true});
> +  let curState = JSON.parse(ss.getBrowserState());
> +  curState.selectedWindow = 2;

Interacting with sessionstore here doesn't do anything, and should be removed.

Comment 6

[Mihaela Velimiroviciu (:mihaelav)]

Attachment: v3

Thanks Blair for the review.
I updated the test as suggested.