1651976 - Perma browser_bug731866.js | Privacy elements should be visible (id=httpsOnlyBox) and browser_bug795764_cachedisabled.js | Privacy element of id=httpsOnlyBox should be visible when Gecko 80 merges to Beta on 2020-07-27

Status: VERIFIED FIXED

(Core :: DOM: Security, defect, P1)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

central-as-beta simulation: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=de9ae70754f6cd7fd622db51ec21e6bbca8d400e&selectedTaskRun=GEH7i6W-SO-cVnVLOWlD_Q.0

Log: https://treeherder.mozilla.org/logviewer.html#?job_id=309289166&repo=try

TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_bug731866.js | Privacy elements should be visible (id=httpsOnlyBox) -
TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_bug795764_cachedisabled.js | Privacy element of id=httpsOnlyBox should be visible -

Comment 1

[Christoph Kerschbaumer [:ckerschb, back Sept 8th]]

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #0)

TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_bug731866.js | Privacy elements should be visible (id=httpsOnlyBox) -
TEST-UNEXPECTED-FAIL | browser/components/preferences/tests/browser_bug795764_cachedisabled.js | Privacy element of id=httpsOnlyBox should be visible -

Gijs, I guess I could use some guidance on how to fix that - can you help me out?

Comment 2

[:Gijs (he/him)]

You'll want to add a block like https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/browser/components/preferences/tests/browser_bug731866.js#23-33 in that test, and a similar block inside https://searchfox.org/mozilla-central/rev/8d55e18875b89cdf2a22a7cba60dc40999c18356/browser/components/preferences/tests/browser_bug795764_cachedisabled.js#37 - basically, you'll want avoid asserting that the item with id httpsOnlyBox is visible on non-nightly.

The "right" thing to do is probably to make your new block read the exposure pref you created, and determine the desired state based on that. Does that help?

Comment 3

[Christoph Kerschbaumer [:ckerschb, back Sept 8th]]

(In reply to :Gijs (he/him) from comment #2)

The "right" thing to do is probably to make your new block read the exposure pref you created, and determine the desired state based on that. Does that help?

Yes it does - thanks!

Comment 4

[Christoph Kerschbaumer [:ckerschb, back Sept 8th]]

Attachment: Bug 1651976: Update test browser_bug731866.js and browser_bug795764_cachedisabled.js to work correctly based on whether HTTPS-Only Mode preference if flipped to true of false. r=gijs

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d4d6783f41b2
Update test browser_bug731866.js and browser_bug795764_cachedisabled.js to work correctly based on whether HTTPS-Only Mode preference if flipped to true of false. r=Gijs,preferences-reviewers

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/d4d6783f41b2

Comment 7

[Intermittent Failures Robot]

1 failures in 5265 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• try: 1

Platform breakdown:

• linux1804-64-shippable: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1651976&startday=2020-07-06&endday=2020-07-12&tree=all

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Verified fixed in today's central-as-beta simulation: https://treeherder.mozilla.org/#/jobs?repo=try&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=1fd50f3457cecf9ac3c1bc6eb8235c1263f49698