Closed
Bug 1276966
Opened 9 years ago
Closed 9 years ago
Stop some tests from accidentally resetting browser.startup.page
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
FIXED
Firefox 49
| Tracking | Status | |
|---|---|---|
| firefox49 | --- | fixed |
People
(Reporter: mconley, Unassigned)
References
Details
Attachments
(1 file)
Our testing profile normally sets this pref to 0:
https://dxr.mozilla.org/mozilla-central/rev/4d63dde701b47b8661ab7990f197b6b60e543839/testing/profiles/prefs_general.js#7
But we have some tests that set that pref, and then use clearUserPref, which resets the preference back to its default, which is 1.
We should probably not do that - we're adding inconsistency with how our tests function, since later tests might rely on browser.startup.page being the testing default of 0.
| Reporter | ||
Comment 1•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/56600/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/56600/
Attachment #8758323 -
Flags: review?(mdeboer)
Comment 2•9 years ago
|
||
Comment on attachment 8758323 [details]
MozReview Request: Bug 1276966 - Fix tests that were accidentally resetting browser.startup.page. r?mikedeboer
https://reviewboard.mozilla.org/r/56600/#review53168
3
::: browser/components/sessionstore/test/browser_480893.js:21
(Diff revision 1)
> let browser = tab.linkedBrowser;
> - promiseBrowserLoaded(browser).then(() => {
> + yield BrowserTestUtils.browserLoaded(browser, false, "about:sessionrestore");
> +
> - let doc = browser.contentDocument;
> + let doc = browser.contentDocument;
>
> - // click on the "Start New Session" button after about:sessionrestore is loaded
> + // click on the "Close" button after about:sessionrestore is loaded
nit: while you're here, can you make it 'Click' and 'loaded.'?
::: browser/components/sessionstore/test/browser_480893.js:41
(Diff revision 1)
> - // click on the "Start New Session" button after about:sessionrestore is loaded
> + browser.loadURI("about:sessionrestore");
> + yield BrowserTestUtils.browserLoaded(browser, false, "about:sessionrestore");
> +
> + doc = browser.contentDocument;
> +
> + // click on the "Close" button after about:sessionrestore is loaded
nit: same here...
::: browser/components/sessionstore/test/browser_480893.js:43
(Diff revision 1)
> +
> + doc = browser.contentDocument;
> +
> + // click on the "Close" button after about:sessionrestore is loaded
> - doc.getElementById("errorCancel").click();
> + doc.getElementById("errorCancel").click();
> - promiseBrowserLoaded(browser).then(() => {
> + yield BrowserTestUtils.browserLoaded(browser, false, homepage);
Isn't it friendlier to our infrastructure and our own sanity perhaps to not have a timeout determine a test failure - I mean, isn't there a more direct deterministic method that can tell us that the correct URL was loaded?
Perhaps using a ContentTask here isn't a bad idea after all, because then you can also circumvent using `browser.contentDocument` here, right?
Attachment #8758323 -
Flags: review?(mdeboer)
| Reporter | ||
Comment 3•9 years ago
|
||
https://reviewboard.mozilla.org/r/56600/#review53168
> nit: while you're here, can you make it 'Click' and 'loaded.'?
Sure, done.
> nit: same here...
Sure, done.
> Isn't it friendlier to our infrastructure and our own sanity perhaps to not have a timeout determine a test failure - I mean, isn't there a more direct deterministic method that can tell us that the correct URL was loaded?
>
> Perhaps using a ContentTask here isn't a bad idea after all, because then you can also circumvent using `browser.contentDocument` here, right?
Okay, after talking with :mikedeboer, I'm going to change this to:
```JavaScript
yield BrowserTestUtils.browserLoaded(browser);
is(doc.URL, homepage, "loaded page is the homepage”);
```
To ensure that we're only checking for the first load of the browser.
| Reporter | ||
Comment 4•9 years ago
|
||
Comment on attachment 8758323 [details]
MozReview Request: Bug 1276966 - Fix tests that were accidentally resetting browser.startup.page. r?mikedeboer
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/56600/diff/1-2/
Attachment #8758323 -
Flags: review?(mdeboer)
Comment 5•9 years ago
|
||
Comment on attachment 8758323 [details]
MozReview Request: Bug 1276966 - Fix tests that were accidentally resetting browser.startup.page. r?mikedeboer
https://reviewboard.mozilla.org/r/56600/#review53248
::: browser/components/sessionstore/test/browser_480893.js:48
(Diff revision 2)
>
> - is(doc.URL, homepage, "loaded page is the homepage");
> + is(browser.currentURI.spec, homepage, "loaded page is the homepage");
>
> - // close tab, restore default values and finish the test
> - gBrowser.removeTab(tab);
> - gPrefService.clearUserPref("browser.startup.page");
> + yield BrowserTestUtils.removeTab(tab);
> +
> + Assert.ok(true, "We made it!");
I think it's already quite obvious that we're done here. If you'd still like to show a message, please change it to `info("We made it!");`
Attachment #8758323 -
Flags: review?(mdeboer) → review+
| Reporter | ||
Comment 6•9 years ago
|
||
https://reviewboard.mozilla.org/r/56600/#review53248
> I think it's already quite obvious that we're done here. If you'd still like to show a message, please change it to `info("We made it!");`
Ah - leftovers from when I didn't have the `is()`, since this test would fail if it didn't have any `is` or `ok` checks. I'll just remove this. Good eye!
| Reporter | ||
Comment 7•9 years ago
|
||
Comment on attachment 8758323 [details]
MozReview Request: Bug 1276966 - Fix tests that were accidentally resetting browser.startup.page. r?mikedeboer
Review request updated; see interdiff: https://reviewboard.mozilla.org/r/56600/diff/2-3/
Pushed by mconley@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/827bd99aa998
Fix tests that were accidentally resetting browser.startup.page. r=mikedeboer
Comment 9•9 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
You need to log in
before you can comment on or make changes to this bug.
Description
•