Make sure HTTPS-Everywhere ships with rules

While fixing #11556 (closed) I realized that our build scripts are not failing when assembling the HTTPS-Everywhere rules breaks. No rules are shipped in our TBBs in this case. We should therefore make sure this issue is detected via our test suite(s).

added component::applications/quality assurance and testing owner::tbb-team parent::33654 priority::medium severity::normal sponsor::58 status::assigned type::enhancement labels

One way to do this is to check whether rules.sqlite in HTTPS-E's defaults directory is existing. An other way would be to look for a special exception thrown during TBB's start-up. (the mozStorageConnection is failing due to the missing rules.sqlite)

Trac:
Description: While fixing #11556 (closed) I realized that our build scripts are not failing when assembling the HTTPS-Everyhwere rules breaks and therefore no rules are shipped in our TBBs. We should therefore make sure this case is detected via our test suite(s).

to

While fixing #11556 (closed) I realized that our build scripts are not failing when assembling the HTTPS-Everyhwere rules breaks. No rules are shipped in our TBBs in this case. We should therefore make sure this issue is detected via our test suite(s).

Trac:
Description: While fixing #11556 (closed) I realized that our build scripts are not failing when assembling the HTTPS-Everyhwere rules breaks. No rules are shipped in our TBBs in this case. We should therefore make sure this issue is detected via our test suite(s).

to

While fixing #11556 (closed) I realized that our build scripts are not failing when assembling the HTTPS-Everywhere rules breaks. No rules are shipped in our TBBs in this case. We should therefore make sure this issue is detected via our test suite(s).

We currently have a test that check that https-everywhere is working by visiting an http URL which has a rule (http://www.mediawiki.org/wiki/MediaWiki) and checking that it results in visiting the https URL (we also check that it doesn't do that when the extension is disabled, in case the website starts redirecting automatically one day). So I think this test would have detected this problem.

But I can also add a test that checks that rulesets.sqlite exists and is not empty just to be sure.

It would probably be a good idea too to check for any exception thrown during TBB start-up, I will check if we can detect that (or if mozmill already makes an error in that case).

Replying to boklm:

We currently have a test that check that https-everywhere is working by visiting an http URL which has a rule (http://www.mediawiki.org/wiki/MediaWiki) and checking that it results in visiting the https URL (we also check that it doesn't do that when the extension is disabled, in case the website starts redirecting automatically one day). So I think this test would have detected this problem.

Nice! Does the test catch corner-cases like a redirection to an HTTPS site on mediawiki's side itself? I could imagine that they implement that one day and then (depending on how the test works) passing might not say much about a functioning HTTPS-E anymore...

But I can also add a test that checks that rulesets.sqlite exists and is not empty just to be sure.

It would probably be a good idea too to check for any exception thrown during TBB start-up, I will check if we can detect that (or if mozmill already makes an error in that case).

Either way seems fine at least to detect the issue I encountered.

Replying to gk:

Nice! Does the test catch corner-cases like a redirection to an HTTPS site on mediawiki's side itself? I could imagine that they implement that one day and then (depending on how the test works) passing might not say much about a functioning HTTPS-E anymore...

Yes, we have a second test that disable HTTPS-E, and loads the same URL to check that it is not redirected to https. So if one day they start redirecting to https on their side, this second test should fail (and we'll have to update the test to use an other URL).

Set all open tickets without a severity to "Normal"

Trac:
Severity: N/A to Normal

Adding S58 on testsuite tickets.

Trac:
Sponsor: N/A to Sponsor58

Grouping all TBB testing tickets under S58O1.1

These will need to be reviewed and re-classified

Trac:
Parent: N/A to #33654 (moved)

Release all this tickets back into tbb-team.

Trac:
Owner: boklm to tbb-team
Status: new to assigned

mentioned in issue #33654 (moved)

moved to tpo/applications/tor-browser-bundle-testsuite#11602