The following test Open the options dialog, sets the home page to default and verifies the page associated with the default home page found in browserconfig.properties file. This test case won't work on Windows until the Bug listed in the "Depends On" section is fixed. It references litmus testcases: * Testcase ID #6287 - Restore Home Page to default

added some minor fixes to the testscript that would have failed under review.

Comment on attachment 378447 [details] testOptions/testRestoreHomeToDefault.js Thanks Aakash, this looks good. But I still have concerns. > // Select the Main Pane in the Preferences Dialog > prefController.click(new elementslib.Lookup(prefController.window.document, '/id("BrowserPreferences")/anon({"orient":"vertical"})/anon({"anonid":"selector"})/{"pane":"paneMain"}')); > prefController.sleep(gDelay); The panes inside the preferences dialog are loaded lazily. Means we should really wait for a specific element. Please wait for the general pane itself. > // Set Home Page to the Default page > prefController.click(new elementslib.ID(prefController.window.document, "restoreDefaultHomePage")); > prefController.sleep(gDelay); So what I miss here is that you set the current homepage to the above loaded page first and check for its assignment via the textbox in the preferences. When you start Firefox from the commandline you will always have the default page already set, so we have to make sure to set another page first. And please don't use gmail because it redirects. Take http://www.mozilla.org instead. > // Close the Preferences Dialog Window > var prefWindow = new elementslib.Lookup(prefController.window.document, '/id("BrowserPreferences")/anon({"orient":"vertical"})/anon({"anonid":"selector"})'); > prefController.keypress(prefWindow,27,false,false,false,false); Can you move this to the teardownModule function? It is just a clean-up and does not have to lay around in the test itself. Can you further please add spaces right behind the commas? > // Check the userAgent of the current build to check for the proper default homepage > var homepage = utils.getProperty("resource:/browserconfig.properties", "browser.startup.homepage"); The comment above doesn't fit to the new way we use here. We don't check for the userAgent anymore. > // Go to the Home page and Verify a Mozilla Branch Project page is in the url bar and loaded > controller.click(new elementslib.ID(controller.window.document, "home-button")); > controller.waitForPageLoad(controller.tabs.activeTab); > > //Verify urlbar with the saved homepage > var addressBar = new elementslib.Lookup(controller.window.document, '/id("main-window")/id("navigator-toolbox")/id("nav-bar")/id("urlbar-container")/id("urlbar")/anon({"class":"autocomplete-textbox-container"})/anon({"anonid":"textbox-input-box"})/anon({"anonid":"input"})'); > if (addressBar.getNode().value != homepage) { > throw "Error: URL in address bar does not match expected '" + homepage +"'"; > } We can't do it that way. Think about official releases. The home page is set to Google search and there is a redirection. Instead please compare the textfield inside the preferences. That should be enough. We have another test which checks if the given home page is really loaded. Some nits: * Please check for whitespaces, unnecessary empty lines, and an identical naming scheme. Sorry that I have to minus it again. But the above parts have to be fixed first.

The preferences dialog API has been implemented. See bug 486407 for an example how to implement it.

Testscript has been updated to take into account changes made for new preferencesDialogAPI. Also, it's not possible to test the current implementation on major releases as the default home page redirects to a different homepage that cannot be called. So, the testscript checks if the "restoreDefaultHomePage" element changes the field to the value from the browserconfig.properties file.

Comment on attachment 384434 [details] [diff] [review] testRestoreHomeToDefault.js >var prefDialogHomePageCallback = function(controller) { > > // Select the Main Pane in the Preferences Dialog > controller.click(new elementslib.Lookup(controller.window.document, '/id("BrowserPreferences")/anon({"orient":"vertical"})/anon({"anonid":"selector"})/{"pane":"paneMain"}')); Same as in the other test. Please user delayedAssertNode to wait for the main pane before clicking on it. > // Set Home Page to the Default page > var browserHomePage = new elementslib.ID(controller.window.document, "browserHomePage"); > controller.click(new elementslib.ID(controller.window.document, "restoreDefaultHomePage")); So you click directly onto the restore default button. That will not help us to detect if the button is really working. Remember that the default page is already set. So you should set the currently open page as home page first. > var defHomePage = browserHomePage.getNode().value; > controller.sleep(gDelay); > > // Check the browserconfig file to get the get default homepage > var homepage = UtilsAPI.getProperty("resource:/browserconfig.properties", "browser.startup.homepage"); > > if (defHomePage != homepage) { > throw "Error: URL in homepage bar" + defHomePage + " does not match expected " + homepage; > } Here you can use the assertValue function now to compare both values. If something will break the test inside the preferences dialog you should also make sure that you reset the updated home page to the default one. Simply add a teardown function and use the PrefsAPI for that.

This should be the last review.

Comment on attachment 384768 [details] [diff] [review] testRestoreHomeToDefault.js This test doesn't use controller.assertValue and also doesn't have a teardown function. Please x-check before requesting a new review. Thanks.

I've updated the missing parts and checked it into the repository: http://hg.mozilla.org/qa/mozmill-tests/rev/0c130169ccfb http://hg.mozilla.org/qa/mozmill-tests/rev/c5e680ad3c01 Marking as 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.