506325 - [mozmill] Test for the Page Info Security tab via the status bar padlock

Status: RESOLVED FIXED

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[u279076]

This is a placeholder bug for creating a Mozmill test script for litmus test 6163 (https://litmus.mozilla.org/show_test.cgi?id=6163)

Comment 1

[Nochum Sossonko [:Natch]]

Please keep in mind that for 3.next this will be changed to a single click on the security icon. Also there's an automated test for this in the tree now...

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Once we branched the Litmus testrun for 3.6 we can check to remove the Litmus test in favor of the automated test. That would also apply to the Mozmill test. We will not need it anymore. So this test will only be for 3.5.

We have to check how to branch the Mozmill-Test repository for the new release.

Comment 3

[u279076]

What's the point in using resources to write a test that will not be used for the next dot-release?

Comment 4

[Nochum Sossonko [:Natch]]

It will be used for the next dot-release (i.e. 3.1.x, 3.0.x) just not for 3.6

Comment 5

[u279076]

Ok...so I think the best approach is to write the test, assuming double click.  I'll comment the code so we know what needs to change when single click is implemented.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Right. But when single click is implemented we will remove this Mozmill test from the trunk version of the mozmill test repository. So it will only resist in the 3.5 branch.

Comment 7

[u279076]

(In reply to comment #6)
> Right. But when single click is implemented we will remove this Mozmill test
> from the trunk version of the mozmill test repository. So it will only resist
> in the 3.5 branch.

Why would we remove the test?  The dialog will still exist, it will just be accessed via single click instead of double click.  Maybe I am not understanding but the BFT will still be valid, so the need of a Mozmill test for the BFT remains.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

In favor of the automated test we will not need the Mozmill test. Nochum, which bug handles this work?

Comment 9

[Nochum Sossonko [:Natch]]

Bug 432741 landed an automated test for single-clicking on the lock icon in the status bar.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Thanks Nochum. So this browser chrome test only covers the click on the lock icon and not anything about the security certificate. So we should leave the litmus test and also need the Mozmill test for 3.6. So we only have to change the dblclick to a single click.

Comment 11

[u279076]

Attachment: Initial test

mozmill-tests is currently down so I can't get a repo to patch.  Here is my actual test.  Please review this.  I'll create a patch later.

NOTE: This test is for Firefox 3.5 only since the padlock works via double click in Firefox 3.5 and single click in 3.6.  Once I have a test checked in for 3.5 I'll post a modified version for 3.6.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 395475 [details]
Initial test

Please let Aakash do the first review from now on.

The repository should be back now. There was a problem with the servers. I will also branch for 3.5 today. So please also update the Litmus id in the test for trunk. Thanks.

Comment 13

[Aakash Desai [:aakashd]]

Comment on attachment 395475 [details]
Initial test


>
>const gDelay = 200;
>

We've beginning to use gDelay=0 and gTimeout=200 as code conventions. This'll matter a down the review.

>var testSecurityInfoViaPadlock = function() {
>  // Go to a secure website
>  controller.open("https://www.verisign.com/");
>  controller.waitForPageLoad(controller.tabs.activeTab);

Make sure to use a waitForElement after a waitForPageLoad as both are pretty necessary for a webpage to not only be up, but also actionable for whatever element (browser and/or content) that you're going to test.


>  // Need to sleep since no controller.waitThenDoubleClick()
>  controller.sleep(gDelay);
>  
>  // Check the Page Info - Security Tab
>  var pageInfoController = new mozmill.controller.MozMillController(mozmill.wm.getMostRecentWindow('Browser:page-info'));
>
>  // Check that the Security tab is selected by default
>  pageInfoController.assertProperty(new elementslib.ID(pageInfoController.window.document, "securityTab"), "selected", "true");

This part is failing for me when running the testscript via command line (on the assertProperty function). I've used the assertProperty in FormManager and Henrik found that, for now, we should use controller.sleep(500); before this command or before instancing the element you are going to assert against (i.e. pageInfoController). I'd suggest replacing controller.sleep(gDelay) to controller.sleep(500).

 

Otherwise, this looks good. Short and sweet, the way I like it :)

Comment 14

[u279076]

> The repository should be back now. There was a problem with the servers. I will
> also branch for 3.5 today. So please also update the Litmus id in the test for
> trunk. Thanks.

Should I just alter the test or submit a second test?  AFAIK, single click will be the way we work for 3.6 and double will be the way we work for all of 3.5.x's life.  In other words, this test would live in the current tests and the single click test would live in the trunk tests...

Comment 15

[u279076]

>>var testSecurityInfoViaPadlock = function() {
>>  // Go to a secure website
>>  controller.open("https://www.verisign.com/");
>>  controller.waitForPageLoad(controller.tabs.activeTab);
>
> Make sure to use a waitForElement after a waitForPageLoad as both are pretty
> necessary for a webpage to not only be up, but also actionable for whatever
> element (browser and/or content) that you're going to test.

Just a quick nit.  If I'm required to do this for every controller.open() we should just put this into controller.open() in the API.  For community test writers, it's really going to be annoying because they will essentially be writing one line of code in three lines.  For reviewers it will be annoying because they'll have to r- every time a controller.open is used without these waitForPageLoad and waitForElement.

Comment 16

[Henrik Skupin [:whimboo][⌚️UTC+1]]

We do not always need waitForElement in content. It's necessary for lets say AJAX heavy sites but normally the elements are present when the page has been finished loading. waitForPageLoad is another topic. It could be combined with open but there has to be a way to not execute this lines if someone doesn't want it. You could file a bug.

Further please use a gTimeout of 5000.

Comment 17

[u279076]

(In reply to comment #16)
> We do not always need waitForElement in content. It's necessary for lets say
> AJAX heavy sites but normally the elements are present when the page has been
> finished loading. waitForPageLoad is another topic. It could be combined with
> open but there has to be a way to not execute this lines if someone doesn't
> want it. You could file a bug.
> 
Based on this and the fact that I am not testing elements in the web page but rather elements in chrome which appear prior to pageLoad I think I am safe to leave waitForElement out of this.  I can see putting it in place if we were seeing lots of failures with controller.click(padlock), but I don't think we are.

> Further please use a gTimeout of 5000.
Will do.

FYI, still awaiting feedback to comment 14...

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

You can attach a patch for 3.5. When it has passed review I can just update it to doubleClick before trunk check-in.

Comment 19

[u279076]

Attachment: Rev1

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Comment on attachment 395683 [details] [diff] [review]
Rev1

Some things have to be updated. I will do it before I check-in the test. Thanks Anthony!

>+// Include necessary modules
>+var RELATIVE_ROOT = '../../shared-modules';

It's not necessary.

>+  controller.open("https://www.verisign.com/");
>+  controller.waitForPageLoad(controller.tabs.activeTab);

controller.tabs.activeTab can be removed as parameter. Just use zero parameters in general from now on.

>+  // Get the information from the certificate for comparison
>+  var cert = controller.window.getBrowser().mCurrentBrowser.securityUI
>+               .QueryInterface(Components.interfaces.nsISSLStatusProvider)
>+                 .SSLStatus.serverCert;  

Assign the first line to its own variable and instead of "Components.interfaces" you can simply write "Ci".

>+  // Press ESC to close the Page Info dialog
>+  controller.keypress(null, 'VK_ESCAPE', {});
>+  
>+}

That will not close the page info window. Just the wrong controller.

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Landed on trunk and 1.9.1:

http://hg.mozilla.org/qa/mozmill-tests/rev/edee6f1e92eb
http://hg.mozilla.org/qa/mozmill-tests/rev/b3db69cf3e80

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.