1246500 - Security errors when displaying a message

Status: RESOLVED DUPLICATE of bug 1269254

(Thunderbird :: Message Reader UI, defect)

Description

[Richard Marti (:Paenglab)]

STR: Start TB and click on a message to read it in the message pane.

Following security errors are shown:
Security Error: Content at mailbox:///C:/Users/Richi/AppData/Roaming/Thunderbird/Profiles/rcu337x7.aaaaaaaaa/Mail/Local%20Folders/test.sbd/test2.sbd/test3?number=6 may not load or link to chrome://communicator/skin/smileys.css.
 ----------
Security Error: Content at mailbox:///C:/Users/Richi/AppData/Roaming/Thunderbird/Profiles/rcu337x7.aaaaaaaaa/Mail/Local%20Folders/test.sbd/test2.sbd/test3?number=6 may not load or link to chrome://messenger/skin/messageQuotes.css.

And when a invitation is viewed this additional security error is shown:
Security Error: Content at mailbox:///C:/Users/Richi/AppData/Roaming/Thunderbird/Profiles/rcu337x7.aaaaaaaaa/Mail/Local%20Folders/Inbox?number=311539 may not load or link to chrome://lightning-common/skin/imip.css.

Another fallout of bug 1195173?

Comment 1

[Richard Marti (:Paenglab)]

Attachment: errorFix.patch

I'm not sure if this would be the way we should go, but it works.

What do you think about this? Should I ask for review?

The strange thing for calendar is, the already existing override to imip.css doesn't work pointing to chrome://lightning but to chrome://calendar. Also to the common directories doesn't work. Because of this I moved imip.css to the calendar theme directories.

Comment 2

[[:MakeMyDay]]

I assume this works because for messagebody is set contentaccessible=yes (although not introduced with this patch).

Following the discussion in bug 1245681 regarding the use of contentaccessible, such seems to be just workaround and not a good way to deal with the fallout of bug 1195173 from security perspective, but I may be wrong here.

Comment 3

[:aceman]

Similar error just opening compose window:
Security Error: Content at about:blank may not load or link to chrome://communicator/skin/smileys.css.

Comment 4

[aleth [:aleth]]

(In reply to MakeMyDay from comment #2)
> Following the discussion in bug 1245681 regarding the use of
> contentaccessible, such seems to be just workaround and not a good way to
> deal with the fallout of bug 1195173 from security perspective, but I may be
> wrong here.

There's still ongoing discussion on the m-c bugs which we should probably wait to see the outcome of, but the patch here is much better than the one in bug 1245681, because it only exposes the desired CSS files and nothing else.

Paenglab: does the relative path issue mentioned here affect your patch? https://developer.mozilla.org/en-US/docs/Chrome_Registration#override

Comment 5

[aleth [:aleth]]

(In reply to aleth [:aleth] from comment #4)
> There's still ongoing discussion on the m-c bugs which we should probably
> wait to see the outcome of, but the patch here is much better than the one
> in bug 1245681, because it only exposes the desired CSS files and nothing
> else.

Sorry, I meant the patch in bug 1246002.

Regardless, it's probably worth pinging bz to find out if this regression is "intentional" or whether it reveals another issue with the changes from bug 1195173.

Comment 6

[Richard Marti (:Paenglab)]

(In reply to aleth [:aleth] from comment #4)
> Paenglab: does the relative path issue mentioned here affect your patch?
> https://developer.mozilla.org/en-US/docs/Chrome_Registration#override

The paths are all absolute in the overriding files -> no problem.

Comment 7

[Richard Marti (:Paenglab)]

(In reply to :aceman from comment #3)
> Similar error just opening compose window:
> Security Error: Content at about:blank may not load or link to
> chrome://communicator/skin/smileys.css.

I was trying for bug 1246002 to override the files like we already do for 'messagebody', but it wasn't needed at the end. I can try to do this for smileys.css too.

Comment 8

[Richard Marti (:Paenglab)]

(In reply to aleth [:aleth] from comment #5)
> Regardless, it's probably worth pinging bz to find out if this regression is
> "intentional" or whether it reveals another issue with the changes from bug
> 1195173.

Boris, what do you think about this?

Comment 9

[Boris Zbarsky [:bzbarsky]]

It really depends on how exactly these CSS files are being loaded (aka the "why did this use to work?" question, given that normally I would expect chrome:// CSS to not be linkable from untrusted content unless contentaccessible=yes).  So how is that being done?

Comment 10

[Richard Marti (:Paenglab)]

Attachment: errorFix.patch

This patch fixes also the security error when opening a composer window.

I'll let it review to look if it would be a possible route.

I also added Ratty to the review because the composer fix affects also SM.

Comment 11

[Boris Zbarsky [:bzbarsky]]

I would really appreciate an answer to my question from comment 9, for what it's worth...

Comment 12

[Richard Marti (:Paenglab)]

(In reply to Boris Zbarsky [:bz] from comment #9)
> It really depends on how exactly these CSS files are being loaded (aka the
> "why did this use to work?" question, given that normally I would expect
> chrome:// CSS to not be linkable from untrusted content unless
> contentaccessible=yes).  So how is that being done?

The contentaccessible=yes is set here https://dxr.mozilla.org/comm-central/source/mail/base/jar.mn#2

chrome://messagebody/ has only one file in it's directory print.css.

The override to messagebody is https://dxr.mozilla.org/comm-central/source/mail/base/jar.mn#5.

Now I override also chrome://messenger/skin/messageQuotes.css and chrome://communicator/skin/smileys.css to messagebody.

In messageBody.css I @import now both css files through url(chrome://messagebody/skin/...

For the error in comment 3 I added now a similar thing to composebody like we do for messagebody. In chrome://composebody/skin/ are only the css files for the smileys and the smiley icons.

Is this explanation okay?

Comment 13

[Boris Zbarsky [:bzbarsky]]

No, because that doesn't explain why the composebody case _used_ to work.

Comment 14

[Richard Marti (:Paenglab)]

(In reply to Boris Zbarsky [:bz] from comment #13)
> No, because that doesn't explain why the composebody case _used_ to work.

The composebody has also the contentaccessible=yes and smileys.css is opened through @import in https://dxr.mozilla.org/comm-central/source/editor/ui/composer/content/EditorContent.css#12 (but with the path changed to composebody now). And EditorContent.css is opened through editor.js (https://dxr.mozilla.org/comm-central/source/editor/ui/composer/content/editor.js#19).

I'm not so an expert in the correlations of all this files. Maybe somebody can explain this better.

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK.  So EditorContent.css is loading?

Christoph, Jonas, this seems like a bug in the new security policy to me at first glance.  We're doing addOverrideStyleSheet to add a chrome sheet to an untrusted document.  This chrome sheet imports other sheets, which are not contentaccessible.  We're denying those loads, presumably because we treat this as triggered by the chrome stylesheet but with the loadingPrincipal set to the untrusted document.

We do NOT want to allow those @imported sheets to be linked to in general, imo.  Only when imported by the sheet that we explicitly added to the document (which should itself probably not be contentaccessible; I don't know whether it is right now).

Comment 16

[aleth [:aleth]]

(In reply to Richard Marti (:Paenglab) from comment #12)
> Now I override also chrome://messenger/skin/messageQuotes.css and
> chrome://communicator/skin/smileys.css to messagebody.

So to summarize this, the issue is that these files are added to content via either

1) addOverrideStylesheet(file1) where file1 contains @import(file2)
2) a messagebody uri (which is contentaccessible) which through an override points at file1 which then @imports file2

In neither case is file2 or file1 itself contentaccessible.

Paenglab: Is this correct? ie. both 1) and 2) occur and this bug is about errors caused by the file2 @import?

Comment 17

[Richard Marti (:Paenglab)]

(In reply to aleth [:aleth] from comment #16)
> Paenglab: Is this correct? ie. both 1) and 2) occur and this bug is about
> errors caused by the file2 @import?

That's correct.

Comment 18

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Boris Zbarsky [:bz] from comment #15)
> OK.  So EditorContent.css is loading?
> 
> Christoph, Jonas, this seems like a bug in the new security policy to me at
> first glance.  We're doing addOverrideStyleSheet to add a chrome sheet to an
> untrusted document.  This chrome sheet imports other sheets, which are not
> contentaccessible.  We're denying those loads, presumably because we treat
> this as triggered by the chrome stylesheet but with the loadingPrincipal set
> to the untrusted document.
> 
> We do NOT want to allow those @imported sheets to be linked to in general,
> imo.  Only when imported by the sheet that we explicitly added to the
> document (which should itself probably not be contentaccessible; I don't
> know whether it is right now).

Your explanation seems reasonable. Overall, I think we need to find a way forward regarding the discussion of whether applying |contentaccessible=yes| to packages or whether to find a better mechanism within the contentSecurityManger. Jonas is on PTO this week, but first thing when he is back, we will discuss how to move forward.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Christoph, it seems like we also broke stylesheet loading from system stylesheets. Not just XBL loading.

I'm guessing the same thing applies to font loading as well, and maybe image loading. Maybe we need to just let anything be loaded when the triggeringPrincipal is system principal :(

Comment 20

[Christoph Kerschbaumer [:ckerschb]]

Richard, can you apply the patch from [1] and check if that fixes the issue within this bug?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1232903#c9

Comment 21

[Richard Marti (:Paenglab)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #20)
> Richard, can you apply the patch from [1] and check if that fixes the issue
> within this bug?
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1232903#c9

I still see the errors with your patch applied (now in m-c).

Comment 22

[Christoph Kerschbaumer [:ckerschb]]

Attachment: debug_securitymanager.patch

Richard, I don't have a TB setup at the moment. I can help you find the root cause of the problem though. Maybe you can apply this debug patch and paste the important parts within this bug. I am wondering what's the loadingPrincipal and TriggeringPrincipal.

Also look out for lines similar to:
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805E0006: file /Users/ckerschb/Documents/moz/mc/dom/security/nsContentSecurityManager.cpp, line 376

which will then tell us what security check exactly failed.

Once we have that information we can find a solution.

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Christoph, I think the nsCORSListenerProxy still gets installed. That might be the problem here.

Comment 24

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jonas Sicking (:sicking) from comment #23)
> Christoph, I think the nsCORSListenerProxy still gets installed. That might
> be the problem here.

Potentially, let's wait what Richard finds out.

Comment 25

[Richard Marti (:Paenglab)]

Christoph, do I need a debug build? I have only a opt build and I see no output from your patch.

Comment 26

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Richard Marti (:Paenglab) from comment #25)
> Christoph, do I need a debug build? I have only a opt build and I see no
> output from your patch.

Not Output at all? That's not possible, because it should print debug information whenever we open a channel. The only thing you don't see with an opt build are those WARNINGs we should look out for, but you should definitely see the printf debug output. Can you generate a debug build by any chance?

Comment 27

[Richard Marti (:Paenglab)]

Attachment: error.log

Log from debug build on showing the message.

Comment 28

[Christoph Kerschbaumer [:ckerschb]]

Jonas, I don't know how we could fix that. Here is what happens, trying to load:

> uri: chrome://messenger/skin/messageQuotes.css
> loadingPrincipal: mailbox:///C:/Users/Richi/AppData/Roaming/Thunderbird/Profiles/rcu337x7.aaaaaaaaa/Mail/Local%20Folders/Inbox?number=500808
> triggeringPrincipal: chrome://messagebody/skin/messageBody.css
> contentPolicyType: 39

which fails the CheckLoadURIWithPrincipal here:
http://mxr.mozilla.org/mozilla-central/source/dom/security/nsContentSecurityManager.cpp#58

Any suggestions?

Comment 29

[Christoph Kerschbaumer [:ckerschb]]

Either way, it's different from the XBL case because the triggeringPrincipal is *not* the systemPricnipal, so maybe we should update Bug 1232903 as well and also check for TYPE_XBL.

Comment 30

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We should probably not do a CheckLoadURIWithPrincipal check if the triggeringPrincipal is the system.

> Either way, it's different from the XBL case because the triggeringPrincipal
> is *not* the systemPricnipal, so maybe we should update Bug 1232903 as well
> and also check for TYPE_XBL.

We still want the user stylesheet to be able to load fonts and images.

Comment 31

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

> Any suggestions?

How did this work before?

Comment 32

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jonas Sicking (:sicking) from comment #30)
> We should probably not do a CheckLoadURIWithPrincipal check if the
> triggeringPrincipal is the system.

Well, the triggeringPrincipal is not the systemPrincipal, it's a |chrome://| principal. See Comment 28 for details.

Comment 33

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Like I said, how did this work before?

Comment 34

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jonas Sicking (:sicking) from comment #33)
> Like I said, how did this work before?

I have been staring at that code for quite some time and in fact, that shouldn't have worked before either. The CheckLoadURIWithPrincipal were only bypassed when aSourcePrincipal was null. In the new code we only create a channel not using the systemPrincipal if principal and node are non null [2,3]. In my opinion, we haven't changed any behavior there. Probably needs more investigation.

Richard, if you are up for some debugging you could check out mc before we landed the changes within Bug 1195173 and figure why CheckLoadURIWithPrincipal was not executed within CheckLoadAllowed.

[1] https://hg.mozilla.org/integration/mozilla-inbound/rev/86d0744f63c6#l2.82
[2] http://mxr.mozilla.org/mozilla-central/source/layout/style/Loader.cpp#1495
[3] http://mxr.mozilla.org/mozilla-central/source/layout/style/Loader.cpp#1621

Comment 35

[Richard Marti (:Paenglab)]

Attachment: errorBeforepatch.log

This is what I get with

c-c cset 4f1b3e5af8ef
m-c cset 5665bf204fe3

and your debug patch.

I'm not a programmer and I don't know how to write debug code for Loader.cpp if needed.

Comment 36

[[:MakeMyDay]]

Christoph, is there already a way forward here?

This breaks invitation preview in Lightning badly - Lightning converts the data from a text/calendar part of a received message (if any) to to a css-styled html document to display the event details. With this bug, all the styles are not applied anymore.

With the upcoming merge this will affect comm-beta. As the Lightning versions for Seamonkey are basing on c-b, this is starting to be an issue latest in another 6 weeks for SM users with calendar, when the respective SM is moving to c-r.

Comment 37

[Christoph Kerschbaumer [:ckerschb]]

(In reply to MakeMyDay from comment #36)
> Christoph, is there already a way forward here?

Unfortunately I don't have time to debug myself, since Thunderbird is in community support only. If you have specific questions, please feel free to ni? me. I think the best way forward is to find someone who can debug what I suggested in Comment 34.

Comment 38

[Jorg K (CEST = GMT+2)]

Attachment: Debug patch adapted from attachment 8725783

I've been asked to debug this. I'm coming late to the party and I don't know anything about security, so forgive me if you already know what I'm saying.

I've debugged this, the patch is attached. Debug below. We note that messageBody.css loads without problems but smileys.css and messageQuotes.css fail.

Fails on CheckLoadURIWithPrincipal(). Stack at the failure point:
DoCheckLoadURIChecks() Line 105	C++
nsContentSecurityManager::CheckChannel() Line 567	C++
nsContentSecurityManager::doContentSecurityCheck() Line 427	C++
nsBaseChannel::AsyncOpen2() Line 700	C++
mozilla::css::Loader::LoadSheet() Line 1727	C++
mozilla::css::Loader::LoadChildSheet() Line 2285	C++

==========  Load from: 'chrome://messagebody/skin/messageBody.css' <=== Worked.

==========  Load from: 'chrome://communicator/skin/smileys.css'
==========  Failed on: 'chrome://communicator/skin/smileys.css' with 805303f4
========== DoCheckLoadURIChecks {
==========  loadingPrincipal: mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/Local%20Folders/Henk.sbd/Test%204?number=7
==========  triggeringPrincipal: chrome://messagebody/skin/messageBody.css
==========  contentPolicyType: 39
==========  securityMode: 4
==========  initalSecurityChecksDone: no
==========  enforceSecurity: yes
==========}

==========  Load from: 'chrome://messenger/skin/messageQuotes.css'
==========  Failed on: 'chrome://messenger/skin/messageQuotes.css' with 805303f4
========== DoCheckLoadURIChecks {
==========  loadingPrincipal: mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/Local%20Folders/Henk.sbd/Test%204?number=7
==========  triggeringPrincipal: chrome://messagebody/skin/messageBody.css
==========  contentPolicyType: 39
==========  securityMode: 4
==========  initalSecurityChecksDone: no
==========  enforceSecurity: yes
==========}

Is this enough information or do you still want me to go back to before bug 1195173 where AsyncOpen was replaced by AsyncOpen2.

Or maybe our config is wrong. If I read this correctly, smileys.css/messageQuotes.css is loaded from a mailbox? Sorry, I may be confused, as I said, I know nothing about this, but if you need more info, I can dig it out for you.

Comment 39

[Jorg K (CEST = GMT+2)]

I've been reading through the bug a bit more. Some/most/all of what I said in comment #38 was known before. The question was raised: How did this work before? Well, before it used AsyncOpen and most likely its processing was different. Will exploring the past really help in finding a fix now that AsyncOpen2 is used. Or are you planning to make AsyncOpen2 more like AsyncOpen?

Comment 40

[[:MakeMyDay]]

Thank you Jorgk for taking a look at this. When digging into it, can you please include the debug output for displaying an invitation email (regardless whether incoming or outgoing), too? I assume it's the same, but it may be different because its done by Lightning. There must be a failure when loading chrome://lightning-common/skin/imip.css

Security Error: Content at imap://caltester1@localhost:143/fetch%3EUID%3E/INBOX%3E21 may not load or link to chrome://lightning-common/skin/imip.css.

Comment 41

[Jorg K (CEST = GMT+2)]

An invitation e-mail gives this debug, similar to the one in comment #38. There seem to be two imip.css that get loaded:

==========  Load from: 'chrome://messagebody/skin/imip.css' <== Worked
==========  Load from: 'chrome://messagebody/skin/messageBody.css'
==========  Load from: 'chrome://messagebody/skin/imip.css' <== Worked
==========  Load from: 'chrome://lightning-common/skin/imip.css'
==========  Failed on: 'chrome://lightning-common/skin/imip.css' with 805303f4
========== DoCheckLoadURIChecks {
==========  loadingPrincipal: mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/Local%20Folders/Henk.sbd/Test%204?number=8
==========  triggeringPrincipal: chrome://messagebody/skin/imip.css
==========  contentPolicyType: 39
==========  securityMode: 4
==========  initalSecurityChecksDone: no
==========  enforceSecurity: yes
==========}

So Load from: 'chrome://messagebody/... seems to work, Load from: 'chrome://(anything else) fails.

Comment 42

[Jorg K (CEST = GMT+2)]

(no offence intended, but the suboptimal English in the summary, well, needed correction)

Comment 43

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

You may have already come to this conclusion, but I believe for the case of @import url(chrome://lightning-common/skin/imip.css); which we have in the actual imip.css the security error is correct.

While chrome://messagebody/skin/imip.css (contentaccessible) is overriden by chrome://lightning/skin/imip.css, the @imported file chrome://lightning-common/skin/imip.css is not contentaccessible and hence should not be loaded.

We could either create chrome://lightning-content/ and chrome://lightning-common-content/ which is contentaccessible and move the respective imip.css into it, or expand the common imip.css back into the theme-specific imip.css. I'd probably go with the former option.

I haven't looked at the non-calendar files, but if there are similar imports then I believe this could be done in the same way. If there is still a security issue in the way urls are loaded, then we should open a new bug in Toolkit as any remaining issues would not be specific to Thunderbird and should be triaged there.

Comment 44

[Richard Marti (:Paenglab)]

Attachment: errorFix.patch

Updated to tip

(In reply to Philipp Kewisch [:Fallen] from comment #43)
> We could either create chrome://lightning-content/ and
> chrome://lightning-common-content/ which is contentaccessible and move the
> respective imip.css into it, or expand the common imip.css back into the
> theme-specific imip.css. I'd probably go with the former option.

Then we would open the chrome://lightning-content/ and chrome://lightning-common-content/ to the world (not sure if the expression is correct). I think my approach in the patch is safer as it opens only the needed files to the world.

Comment 45

[Jorg K (CEST = GMT+2)]

I think we should get confirmation that what we've been doing so far is wrong and then go with Richard's approach. These security errors no only cause loss of icons, but also loss of correct visualisation of reply depth (and that annoys me ;-().

"Open to the world" sounds correct, Aleth used "exposes way files to content" (bug 1246002 comment #1). Being a complete security ignorant I still don't know why this is bad. So a message could use our CSS files. So how can that do any damage?

Comment 46

[Jorg K (CEST = GMT+2)]

Oops, I quoted that badly: "exposes ... files to content"

Comment 47

[aleth [:aleth]]

(In reply to Jorg K (PTO during summer, NI me) from comment #45)
> "Open to the world" sounds correct, Aleth used "exposes way files to
> content" (bug 1246002 comment #1). Being a complete security ignorant I
> still don't know why this is bad. So a message could use our CSS files. So
> how can that do any damage?

The point is to organize the files/URIs so that only the files that need to be exposed get exposed. That comment referred to a patch which was exposing a large number of JS files as well.

Comment 48

[Jorg K (CEST = GMT+2)]

Thanks, but please explain what bad consequences "exposing" can have.

Comment 49

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

(In reply to Richard Marti (:Paenglab) from comment #44)
> Then we would open the chrome://lightning-content/ and
> chrome://lightning-common-content/ to the world (not sure if the expression
> is correct). I think my approach in the patch is safer as it opens only the
> needed files to the world.

This would be the point. Only files that /should/ be exposed to the world (like imip.css) would be moved to lightning-content and lightning-common-content. Everything else stays where it is. The advantage with this approach is that you make clear that the file is exposed to content and can keep any imports, like those used for splitting common from per-OS css, as long as you move the imports to the same package.



(In reply to Jorg K (PTO during summer, NI me) from comment #48)
> Thanks, but please explain what bad consequences "exposing" can have.

I think there may be a misunderstanding. I don't see any bad consequences from exposing (simple) css files. If you start exposing js or even services, then may become an issue.

Comment 50

[Magnus Melin [:mkmelin]]

Even if it's a "simple" css, with time that can change, and someone adds an xbl binding...

Mostly the danger is that you're increasing the attack surface. If you allow someone to load a chrome file arbitrarily, maybe you find some other flaw that allows you to run that script, and that script happens to say delete all of your accounts. Basically I don't think it's a supported configuration to *safely* run mixed remote and chrome content.

Even with just css it also allows some fingerprinting of course. E.g. hide remote content using a css rule from lightning with display:none to see if people have lightning installed or not.

Comment 51

[[:MakeMyDay]]

Lightning is not running remote content directly. The vector is much smaller here than it is for email, if any.

Lightning is just overlaying the message body, which currently has _no_ rendered content in case of invitations (as visible with Lightning disabled). And even if bug 505024 may change that one day, the then visible content doesn't have to be treated different from other mails from Lightning perspective.

What is actually missing is the abbility to load a css file to decorate the Lightning internal html document which is used as overlay. For its content data from the ics part of the message are extracted and parsed first. This content is only rendered as plain text (with the exception of formating using mozITXTToHTMLConv) without loading remote content.

We maybe can work around this by using an inline css definition in the html document, but that would be obviously no solution for the other not Lightning related parts of this bug, so we should find a more general solution here.

Comment 52

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jorg K (PTO during summer, NI me) from comment #38)
> Is this enough information or do you still want me to go back to before bug
> 1195173 where AsyncOpen was replaced by AsyncOpen2.

That is indeed enough information. Initially I thought the TriggeringPricnipal is the SystemPrincipal, but that is not the case, the triggeringPrincipal is a codebosePrincipal of 'chrome://' which is exactly the same problem we are dealing with in Bug 1269254 [1]. I am almost certain that fixing Bug 1269254 will also fix this bug. (And we really need to fix Bug 1269254 soon, so stay tuned).

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1269254#c3

Comment 53

[Jorg K (CEST = GMT+2)]

Christoph, thanks for your feedback and your support in this case. We'll stay tuned.

I'm sure you saw that the failure occurs on CheckLoadURIWithPrincipal(loadingPrincipal, ...) before the triggeringPrincipal is checked a few line further down. Since your initial debug patch had provision to dump out triggeringPrincipal, I retrieved it just to dump it out for completeness.

Comment 54

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jorg K (PTO during summer, NI me) from comment #53)
> Christoph, thanks for your feedback and your support in this case. We'll
> stay tuned.

Jorg, does this patch [1] fix the problem? I think it does, but want to make sure.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1269254#c18

Comment 55

[Richard Marti (:Paenglab)]

(In reply to Christoph Kerschbaumer [:ckerschb] from comment #54)
> Jorg, does this patch [1] fix the problem? I think it does, but want to make
> sure.
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1269254#c18

Stealing Jörg's feedback. Yes, this fixes the problem. :)

Comment 56

[Jorg K (CEST = GMT+2)]

Attachment 8753481 [details] [diff] fixes this bug here - Thanks!

1) quotes work
2) smileys work
3) invitation e-mails work.

Comment 57

[Jorg K (CEST = GMT+2)]

Set severity to "blocker" since without this bug fixed, TB is basically not usable since our style sheets don't get loaded and therefore we can't display a single message correctly.

Comment 58

[Jorg K (CEST = GMT+2)]

Now that bug 1269254 has landed, let's close this after trying it out in Daily tomorrow.

Comment 59

[Jorg K (CEST = GMT+2)]

This works now. I'm making this a duplicate of bug 1269254 so we automatically hear about updates.
This regressed into TB48 and I have therefore requested uplift in bug 1269254.