1525834 - ReferenceError: reference to undefined property "STATE_SECURE_HIGH" in specialTabs.js:151:1

Status: RESOLVED FIXED

(MailNews Core :: General, enhancement)

Description

[:aceman]

Opening Help->Troubleshooting info I get:
ReferenceError: reference to undefined property "STATE_SECURE_HIGH" in specialTabs.js:151:1

Looks like STATE_SECURE_HIGH constant does not exist anymore in m-c.
See
https://searchfox.org/comm-central/search?q=STATE_SECURE&case=false&regexp=false&path= these constants are aonly used in c-c a multiple places. This needs some update.

Trangely the STATE_SECURE_* constants are still mentioned in m-c comment at https://searchfox.org/comm-central/source/mozilla/uriloader/base/nsIWebProgressListener.idl#171 , but defined nowhere.

Looks like bug 1095602.

Comment 1

[:aceman]

Attachment: 1525834.patch [landed in comment #7 without the Calendar hunks]

Comment 2

[Richard Marti (:Paenglab)]

Comment on attachment 9042742 [details] [diff] [review]
1525834.patch [landed in comment #7 without the Calendar hunks]

Could the attributes be "secure" and "insecure" instead of "secure" and "broken"?

Comment 3

[:aceman]

According to https://searchfox.org/comm-central/source/mozilla/uriloader/base/nsIWebProgressListener.idl#156 "insecure" and "broken" are different states. I think the patch keeps all 3 states distinguished (insecure sets no level and hides securitybutton, e.g. https://searchfox.org/comm-central/source/mail/base/content/browserRequest.js#71).

Comment 4

[Frank-Rainer Grahl (:frg)]

Comment on attachment 9042742 [details] [diff] [review]
1525834.patch [landed in comment #7 without the Calendar hunks]

Looks good Thanks+++

IanN: No change needed for the status bar I think. Only uses high.

Comment 5

[Frank-Rainer Grahl (:frg)]

Comment on attachment 9042742 [details] [diff] [review]
1525834.patch [landed in comment #7 without the Calendar hunks]

Upps set wrong reviewer

Comment 6

[Jorg K (CEST = GMT+2)]

I don't think the gData bit is right. gData tries to maintain compatibility with earlier versions of TB. You might also want to ask MMD for review. I'm going to land the non-Calendar bits now.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/25a47ea601f0
Port bug 1095602: Remove STATE_SECURE flags from nsIWebProgressListener. r=mkmelin,frg ui-r=Paenglab

Comment 8

[:aceman]

Attachment: 1525834-cal.patch

Yes, thanks.

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

Comment on attachment 9042769 [details] [diff] [review]
1525834-cal.patch

Review of attachment 9042769 [details] [diff] [review]:
-----------------------------------------------------------------

Generally you are right, I try to maximize the compatibility for gdata. In this case I think it is fine nevertheless, the new code works with the old m-c code as well, we are just a bit less granular.

Comment 10

[Jorg K (CEST = GMT+2)]

Right, reading bug 1095602 comment #0 and https://hg.mozilla.org/mozilla-central/rev/b83cac4f938a, there was only ever a combination of "secure + high" used. "High" didn't occur alone and the other two were never used. I'll get this landed.

Comment 11

[Jorg K (CEST = GMT+2)]

Comment on attachment 9042769 [details] [diff] [review]
1525834-cal.patch

Gotta love the spurious "y" at the end of the patch :-)

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6eac5062e8a1
Port bug 1095602: Remove STATE_SECURE flags from nsIWebProgressListener in calendar/. r=philipp

Comment 13

[Jorg K (CEST = GMT+2)]

TB 66 beta 2:
https://hg.mozilla.org/releases/comm-beta/rev/0d11393715e4a7f6a79d54b742e21f0c7b3378a2
https://hg.mozilla.org/releases/comm-beta/rev/fbdbfa0e0fe379c3458212a84e8b58b0245d5863