When Thunderbird trunk (7.0a1) is in online mode, but can't reach the network, a yellow XML missing entity error is displayed instead of the start page, because the entity corruptedContentError.title is missing. That was introduced by bug 651486 and needs to be added to mail's netError.dtd. Furthermore, I'm going to fix bug 435325 (Offline-mode error page should switch to online mode when clicking 'Try Again') soon, which changes an entity. The patch addresses both issues. Tested locally. I'll check it in at the same time as bug 435325 to avoid breakage, even if it's not reviewed by then; hope that's ok. I'm aware of bug 653386, but that is not urgent.

The error page for NS_ERROR_CORRUPTED_CONTENT was introduced by bug 662414, not bug 651486.

While it's nice to see core_dev thinking about the TB app, Protocol suggests that R+ is applied before checkin. Otherwise we get into "He said/She said" or the ever popular _ass_ _ume_ protocol.

I would've included this fix in my patch in bug 435325, but that wasn't possible because comm-central is a separate repo. That bug includes a test, which IIUC would turn the Thunderbird builds orange as soon as they're enabled on comm-central again. So this is in the bustage/orange-fix category. Also note that string-freeze for Thunderbird 7 is only ca. 4 weeks away...

Thanks for thinking of us. I would say though that for string changes we need to be careful, even if it busts Thunderbird trunk - if our UX review is minus because there's some wording that should be slightly different for Thunderbird, then we're in the situation where changing those strings may be difficult, because some of the locales that translate comm-central may have already translated them, and the only clean way to get out of it would be to bump the string ids again (and hence affecting both mozilla-central and comm-central locales). In future though, there's some hope - we're setting up a new system that will provide us a buffer against breakage, so we shouldn't need to rush-fix some of these things.

Comment on attachment 538672 [details] [diff] [review] patch Review of attachment 538672 [details] [diff] [review]: ----------------------------------------------------------------- So, I think the changes makes sense, so I'm going to say "r=me". But, the wording does seem a little odd in Thunderbird's context, so I'm going to give it a ui-r-, in the hopes that we can fix that before checking it in. (If that's a major pain in the ass, I would settle for a followup bug to fix the wording.) Thanks, Blake. ::: mail/locales/en-US/chrome/overrides/netError.dtd @@ -165,3 +165,5 @@ > > <!ENTITY cspFrameAncestorBlocked.title "Blocked by Content Security Policy"> > > <!ENTITY cspFrameAncestorBlocked.longDesc "<p>&brandShortName; prevented this page from loading in this way because the page has a content security policy that disallows it.</p>"> > > > > +<!ENTITY corruptedContentError.title "Corrupted Content Error"> > > +<!ENTITY corruptedContentError.longDesc "<p>The page you are trying to view cannot be shown because an error in the data transmission was detected.</p><ul><li>Please contact the website owners to inform them of this problem.</li></ul>"> Does it make sense to talk about viewing pages, and website owners in the context of Thunderbird? (For something like WebTabs, it certainly would, but if we're going to see this in the Start Page under the list of messages, I'm not so sure...) How about "<p>The content you are trying to view cannot be shown because an error in the data transmission was detected.</p><ul><li>Please contact the owners to inform them of this problem.</li></ul>" instead?

It's already checked in, and I can't believe 6 locales already picked it up just 24 hours afterwards, on comm-central (Thunderbird 7) trunk! I'm cc'ing thunderbird@localization.bugs to let them know that corruptedContentError.longDesc will change again. (In reply to comment #6) > (If that's a major pain in the ass, I would settle for a followup bug to fix > the wording.) No pain for me at all. I'm sorry for wasting a bit of awesome localizers' time. > Does it make sense to talk about viewing pages, and website owners in the > context of Thunderbird? (For something like WebTabs, it certainly would, > but if we're going to see this in the Start Page under the list of messages, > I'm not so sure...) Yes, I noticed that in the start page.

> How about "<p>The content you are trying to view cannot be shown because an > error in the data transmission was detected.</p><ul><li>Please contact the > owners to inform them of this problem.</li></ul>" instead? Sounds fine to me, and here's the patch.

Comment on attachment 538927 [details] [diff] [review] change corruptedContentError.longDesc per comment 6 Looks good to me, but I would like to get Mark's feedback on the l10n impact before we commit this. Thanks, Blake.

I'd say sooner is better than later, before more locales pick that up - 7 already did so :-O http://mxr.mozilla.org/l10n-central/search?string=corruptedContentError.longDesc&find=mail&findi=&filter=^[^\0]*%24&hitlimit=&tree=l10n-central I'd suggest to check-in asap, and post to mozilla.dev.l10n.

Comment on attachment 538927 [details] [diff] [review] change corruptedContentError.longDesc per comment 6 I think whilst this isn't ideal from the l10n perspective, we should probably change it anyway, and let the l10n teams know. This will avoid bumping the strings for everyone on mozilla-central as well. If a localisation has a translation from the original, it isn't a big issue, though ideally we'd like the new version.

I checked that into comm-central, and posted to m.d.l10n. http://hg.mozilla.org/comm-central/rev/6d46dca5b7cf

Hi folks, I'm the manager of one of those seven locales that translated the string before it was fixed. I have a little practical question: doesn't it sound a bit weird to refer to "content", and especially to its owners in this way? For me it sounds a bit blurry. Maybe it would make sense to change the suggestion sentence ("Please contact the owners to inform them of this problem.") to something like "Please try again later." or to remove it alltogether?

Fixed for lt nevertheless: http://hg.mozilla.org/l10n-central/lt/rev/62173c1cd3e0

Any thoughts on Rimas's suggested wording, Steffen? Thanks, Blake.

If this error occurs, something fishy is likely going on (HTTP response smuggling), see bug 597706 comment 0. IIUC, you've either hit a malicious/hacked site, or someone is MITM you. So I don't think that "try again later" is a particular helpful suggestion. The current suggestion to inform the website/content owners might at least help in the case that the owners don't know that their site has been hacked.