Add automated test for installing add-ons in private browsing

NEW
Unassigned

Status

()

Firefox
Private Browsing
3 years ago
3 years ago

People

(Reporter: mihaelav, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

3 years ago
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).
(Reporter)

Comment 1

3 years ago
Created attachment 8577205 [details] [diff] [review]
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!
Attachment #8577205 - Flags: review?(ttaubert)
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.
Attachment #8577205 - Flags: review?(ttaubert) → feedback?(bmcbride)
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
Attachment #8577205 - Flags: feedback?(bmcbride) → feedback-
(Reporter)

Comment 4

3 years ago
Created attachment 8583112 [details] [diff] [review]
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.
Attachment #8577205 - Attachment is obsolete: true
Attachment #8583112 - Flags: review?(bmcbride)
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.
Attachment #8583112 - Flags: review?(bmcbride) → review+
(Reporter)

Comment 6

3 years ago
Created attachment 8587832 [details] [diff] [review]
v3

Thanks Blair for the review.
I updated the test as suggested.
Attachment #8583112 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.