Closed Bug 514528 Opened 10 years ago Closed 10 years ago

[mozmill] testSSLDisabledErrorPage.js fails

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: whimboo, Assigned: ashughes)

References

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file, 1 obsolete file)

Test Failed : testDisableSSL in c:\mozilla\tests\firefox\testSecurity\testSSLDis
abledErrorPage.js

ERROR - Test Failure: {'exception': {'message': 'timeout exceeded for waitForEle
ment ID: errorTitleText', 'lineNumber': 306

Due to bug 513129 the above Mozmill test fails. Even after disabling both secure protocols we still fetch the content from the cache. To fix this test we should clear the cache before loading the Verisign page.

Anthony, could you please have a look at this bug?
Assignee: anthony.s.hughes → ashughes
Depends on: 513129
Assignee: ashughes → anthony.s.hughes
(In reply to comment #0)
> Test Failed : testDisableSSL in
> c:\mozilla\tests\firefox\testSecurity\testSSLDis
> abledErrorPage.js
> 
> ERROR - Test Failure: {'exception': {'message': 'timeout exceeded for
> waitForEle
> ment ID: errorTitleText', 'lineNumber': 306
> 
> Due to bug 513129 the above Mozmill test fails. Even after disabling both
> secure protocols we still fetch the content from the cache. To fix this test we
> should clear the cache before loading the Verisign page.
> 
> Anthony, could you please have a look at this bug?

What is a sufficient method to clearing the cache?  Is Tools > Clear Recent History > Time: Everything | Details: Cache enough?
Please try the manual steps in bug 513129 comment 1 and if it helps to clear the Cache that way. We could also make use of a XPCOM component without touching the CRH dialog.
(In reply to comment #2)
> Please try the manual steps in bug 513129 comment 1 and if it helps to clear
> the Cache that way. We could also make use of a XPCOM component without
> touching the CRH dialog.

Bug happens as described in bug 513129 comment 1 on Namoroka and Shiretoko.  However, the bug is not reproducible on Minefield.  See bug 513129 comment 19.
Clearing the cache works around this issue (Tools > Clear Recent History > Cache)
http://mxr.mozilla.org/mozilla1.9.1/source/browser/base/content/sanitize.js#123

Looks like this is the code responsible for clearing the cache.  Henrik, can you please advise?
See my Mozmill test attached to bug 513129. I have already tried that way but without success. Seems like there is another point we are missing here.
From bug 513129:
>As long as we can't run tests under httpd+ssltunnel please simply use another >website to do the verification check. One we don't use in all of our other tests.

I'm not sure what specifically we can use here instead of https://www.verisign.com.  I've tried various EV-SSL (green) sites and they all fail with your minimized test:

https://www.digicert.com/
https://www.starfieldtech.com/
https://buy.entrust.net/buy/index.cfm?csrtype1=ev&csrtype2=ev&certlife1=1
https://www.thawte.com/
https://www.godaddy.com/
https://addons.mozilla.org/en-US/firefox/?browse=featured
From bug 513129:
>As long as we can't run tests under httpd+ssltunnel please simply use another
>website to do the verification check. One we don't use in all of our other tests.

I'm not sure what specifically we can use here instead of
https://www.verisign.com.  I've tried various EV-SSL (green) sites and they all
fail with your minimized test:

https://www.digicert.com/
https://www.starfieldtech.com/
https://buy.entrust.net/buy/index.cfm?csrtype1=ev&csrtype2=ev&certlife1=1
https://www.thawte.com/
https://www.godaddy.com/
https://addons.mozilla.org/en-US/firefox/?browse=featured
I don't see that problem anymore when simply applying the fix as below (which do not update additionally checks):

-  controller.open("https://www.verisign.com");
+  controller.open("https://www.google.com");

We only have to make sure to use 'https://www.google.com' only for this single test inside the testSecurity folder.
Whiteboard: [mozmill-test-failure]
Heh...I didn't even know google had an https site.  I'll try that out locally thanks.
It's brand new. AFAIR it was born a week ago. The good thing is it's quite fast but sadly no EV site. So it's fine for this test.
(In reply to comment #11)
> It's brand new. AFAIR it was born a week ago. The good thing is it's quite fast
> but sadly no EV site. So it's fine for this test.

Google will not work in this case.  I checked the test and we get a dialog saying SSL has been disabled, not an error page.  This test checks for existance of an error page not a popup.

I think we need an EV SSL site to generate the error page.
(In reply to comment #12)
> Google will not work in this case.  I checked the test and we get a dialog
> saying SSL has been disabled, not an error page.  This test checks for
> existance of an error page not a popup.
> 
> I think we need an EV SSL site to generate the error page.

If a dialog popups up then it is a bug in Firefox. See bug 457021 for more information. I have tested it yesterday and wasn't able to get into that situation. That said, this situation could happen for all secure connections. Probably you have run other tests before? If you have a test which constantly reproduces the problem for you with all versions of Firefox please attach it here. We can use it as a testcase for bug 457021.
I simply replaced "https://www.verisign.com" with "https://www.google.com" in your minimized testcase for bug 513129 (https://bugzilla.mozilla.org/attachment.cgi?id=418172).  Every time I run it I get the popup dialog, not the SSL error page.
This test doesn't play into account for our real test. The minimized test loads the secure website twice. I believe you have replaced both versign entries with google. You should only do this for the 2nd instance in testDisableSSL and not in setupModule.
Ok, I'll try it out with the actual testSSLDisabledErrorPage.js.
Attached patch Patch v1 (default) (obsolete) — Splinter Review
Attachment #451170 - Flags: review?(hskupin)
Comment on attachment 451170 [details] [diff] [review]
Patch v1 (default)

>-  controller.open("https://www.verisign.com");
>+  controller.open("https://www.google.com");

Have you seen the comment from Boris on the other bug? I think it's a good idea to also disable keep-alive completely for this test. We can keep Google as reference page.
(In reply to comment #18)
> (From update of attachment 451170 [details] [diff] [review])
> >-  controller.open("https://www.verisign.com");
> >+  controller.open("https://www.google.com");
> 
> Have you seen the comment from Boris on the other bug? I think it's a good idea
> to also disable keep-alive completely for this test. We can keep Google as
> reference page.

Disable the pref and keep using Verisign?
(In reply to comment #19)
> Disable the pref and keep using Verisign?

Correct, but lets keep Google. It's a way much faster and we can save a couple of seconds here. That way we could also modify other general SSL tests to use Google in the future without colliding again with keep-alive.
Added Disabling of Keep-alive to setupModule and Enabling of Keep-alive to teardownModule.  This ensures it is disabled before the test starts and re-enabled once the test finishes.

Once bug 513129 is resolved we should be able to remove this code.
Attachment #451170 - Attachment is obsolete: true
Attachment #451354 - Flags: review?(hskupin)
Attachment #451170 - Flags: review?(hskupin)
Comment on attachment 451354 [details] [diff] [review]
Patch v1.1 (default)

>   PrefsAPI.preferences.clearUserPref("security.enable_tls");
>+  
>+  // XXX: Bug 513129
>+  //      Re-enable Keep-alive connections
>+  PrefsAPI.preferences.setPref("network.http.keep-alive", false);

That should also be a clearUserPref. I will fix it before the check-in.

r=me
Attachment #451354 - Flags: review?(hskupin) → review+
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.
Component: Security → Mozmill Tests
Product: Firefox → Mozilla QA
QA Contact: firefox → mozmill-tests
Version: Trunk → unspecified
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.