After the new error pages land (bug 280190), the error descriptions should be analyzed once again and improved wherever possible before the localization freeze. There are some parts which could be re-worded and made much more user friendly and efficient. It's better to have the opinion of people who handle the help system, becuase I'm sure that they can express themselves better :) I'll CC a few people who might be of help.

The current strings are at http://lxr.mozilla.org/mozilla/source/dom/locales/en-US/chrome/netError.dtd

Mention of configuring software/personal firewalls would be good, that's one of the most common issues over at MozillaZine forums (especially after a user has upgraded and their firewall decides to block the modified exe).

note also my comments in bug 280190 comment 153

(In reply to comment #3) > note also my comments in bug 280190 comment 153 William, could you take a look on that part?

Also see bug 280190 comment 170

This should block 1.8b4 since it has an l10n impact.

Mike, can you take a look through these strings and see if we need to make changes before 1.5? If so, it needs to happen before 1.8b4.

(In reply to comment #7) > Mike, can you take a look through these strings and see if we need to make > changes before 1.5? If so, it needs to happen before 1.8b4. Reviewing now ...

(In reply to comment #8) > (In reply to comment #7) > > Mike, can you take a look through these strings and see if we need to make > > changes before 1.5? If so, it needs to happen before 1.8b4. > > Reviewing now ... There is no point in doing this right now since the new error pages haven't been checked in yet, so the strings you're currently looking at will all be replaced. Bug 280190 attachment 189994 [details] [diff] [review] has the new strings at the bottom, but since it hasn't landed yet it would be kinda difficult to post patches. Maybe it would be best to set up a Wiki page with all the errors+descriptions and handle the changes there, and once it's done to just create a patch?

OK, I set up a wiki to store the changes pending bug 280190. For now, we'll edit these messages collaboratively at http://wiki.mozilla.org/Firefox:1.5_Network_Error_Messages Some notes about the changes I made: - used a more conversational voice - tried to simplify terminology - used sentence capitalization for text Some things to consider: - should we be asking questions? why not just provide suggestions? - will we have access to things like the page the user tried to load?

Well done Mike. One note though, it seems that we have a little problem with using "Firefox" (the brand name) in the text, see bug 302309.

(In reply to comment #11) > One note though, it seems that we have a little problem with using "Firefox" > (the brand name) in the text, see bug 302309. Do we need to nominate that one for blocking1.8b4? Or can we just use seperate DTDs for each product? I'd really rather that we be able to use the product name than "the browser" everywhere. There are several comments in the wiki that I'm looking at, too: - changing some of the questions so that they're helpful, not interrogating - replacing "this address" with the address that caused the problem - should we use contractions? I'm for it for "can not" and "is not" for friendliness

Made some more updates; tried removing all the questions (don't panic! we can go back) and replaced them with suggestions of possible ways to fix the problem. Please see "Open issues & questions" when reviewing.

If we want to use &brandShortName; instead of "browser", bug 302309 has to be fixed ASAP. Otherwise we aren't able to use this entity from within netError.dtd for now.

Here's what's currently proposed in patch format. The patch doesn't work as is now because the entities have to be valid JS strings, and unescaped newlines are invalid. If anyone posts updated versions of the patch, please keep the formatting as is (newlines, indentation, 80-character lines, etc.) to make reviewing easier. We can post a working patch when we have the wording finalized. (In the meantime I'm trying to fix this problem in bug 302729, although I don't know yet whether I'll be able to do so or not.) It'd be really good if we could have comments on the changes posted here instead of in the wiki, because the wiki has to be manually checked whereas bugmail is automated.

Currently the areas covered when a website can't be found are : * mistake typing * expired domain * local network connection settings * firewall I question the usefulness of mentioning "Has the domain's registration expired?" as most users won't know one way or the other, and will not know how to check such a thing. I also wonder aloud if there should be some mention of high network traffic perhaps being responsible (packet loss) or ISP-related problems, and/or some mention that it might be the fault of the server the user is trying to contact (high load, not online, experiencing problems, down for maintanance, etc).

(In reply to comment #10) > - used a more conversational voice I think contractions such as "can't" and "isn't" seem out of place. I suggest replacing "can't" with "cannot" and phrases such as "isn't available" with "is unavailable".

The new version of Epiphany in the upcoming GNOME 2.12 uses Gecko 1.8, and they have new user-friendly error messages, here's a screenshot: http://www.gnome.org/~davyd/gnome-2-12/images/epiphany-errorpage.png I like the concept of "If this page doesn't exist, you may find an archived version..."

Updated with changes as suggested on the wiki (removed contractions from headers; changed some of the suggested fixes) I'm still not entirely happy with all of the headers, so please feel free to propose changes. Contractions in the second-level text should be retained, IMO, as they are a much friendlier read; I'll admit that they look kind of strange in the headers. Some notes & open questions for comment: * Safari uses "Safari can't do this .." or "Safari wasn't able to do that" in their headers. Do we want to do something similar? It's way friendlier, but steps away from more familiar and to the point summaries of what went wrong. * there are some cases where the "Try Again" button makes no sense. Is there a way to remove it for some of the messages?

no longer a branch blocker since what we have is minimally sufficient (for localizers) but if we're going to take further changes, we should get them in ASAP.

Made a couple more small changes. I'd like for this to be wrapped up by Friday EOD, so please throw in comments if you have any. changes - removed "" around "offline mode" and added a ", and try again" - changed header for generic error (after a lot of internal debate) to "Oops", since we can't really give any good diagnostic information, and might as well be friendly (there are a lot of other programs that take this approach, and it seems to work; see Gmail for an example)

- Changed protocolNotFound to be more technically accurate and easier to understand - changed button label back to "Try Again" to be consistent with HIG (my bad)

Some final changes to protocolNotFound.

Hm. Looking closer, I think what I actually want to do is strip out the first line of each of these revised error mesages and put them into mozilla/dom/locales/en-US/chrome/appstrings.properties. That way the new error message for, say, conectionFailure would look like: __________________________________________________________________ / \ | . Unable to connect | <-- [1] | /!\ -------------------------------------------------------- | | --- Firefox can't establish a connection with the server at | <-- [2] | http://www.somebrokenserver.com | | -------------------------------------------------------- | | * The site could be temporarily unavailable or too busy. | <-- [3] | Try again in a few moments. | | | | * If you are unable to connect to any addresses, check | | the computer's network connection. | | | | * If your computer or network is protected by a firewall | | or proxy, make sure that Firefox is permitted to access | | the Web. | | | | [Try Again] | \__________________________________________________________________/ where, [1] comes from the netError.dtd "<errorType>.title" attribute [2] comes from the appstrings.properties file [3] comes from the netError.dtd "<errorType>.longDesc" attribute

So, once I learn how to make patches, I'll make this into a patch, but this is what I think we'd need to change appstrings.properties to :) (and then we'd have to take the equivalent strings *out* of netError.dtd)

some notes about appstrings.properties the texts in that file are the ones that are shown in the error dialog when error pages are disabled (some apps like camino (I think) disable them by default) it's much easier to use the app name in appstrings.properties, because it is actually possible to handle the case that the application doesn't specify its name.

Might it be better to use "ww.example.org" and "www.example.org" in place of "ww.mozilla.org" and "www.mozilla.org"?

spec reserves example.com (not .org), so if you want to use something, that's usually the right thing.

(In reply to comment #28) > spec reserves example.com (not .org), so if you want to use something, that's > usually the right thing. .com, .org and .net are all reserved - http://rfc.net/rfc2606.html#s3.

Yeah, will update to (In reply to comment #27) > Might it be better to use "ww.example.org" and "www.example.org" in place of > "ww.mozilla.org" and "www.mozilla.org"? Oops. Yes. It would. I'll update the patch when I find some hardware that's not borrowed, or more accurately, some hardware that has the right software. I'll also reformat non-pretty-printed for the DTD and post a patch of the appstrings file in order to see if we can wrap this up.

Comment on attachment 191751 [details] [diff] [review] v5 with pretty printing >+<!ENTITY connectionFailure.title "Unable to connect"> >+ [li]If you are unable to connect to any addresses, check the computer's >+ network connection.[/li] Why not "your computer's" instead of "the computer's"? It's more personal, and we're trying to make these errors user-friendly. It also fits better with "your computer" in the next bullet. >+ [li]If your computer or network is protected by a firewall or proxy, make >+ sure that Firefox is permitted to access the Web.[/li] >+[/ul] >+"> Note also that because we're using this in a couple other entities (netInterrupt, netReset, netTimeout), we need to make the fixes there too. Perhaps we should split it out into a new, internal entity that's used in the creation of these so as to have less duplication. >+<!ENTITY deniedPortAccess.title "This port is restricted"> >+<!ENTITY deniedPortAccess.longDesc " >+[p]This address (%S) specifies a network port which is normally used for >+ purposes other than Web browsing. Firefox has canceled the request for your >+ protection.[/p] >+"> Realistically, can we expect the average user to know what a network port is? I'm not sure what the fix is here, because we can't really obfuscate here (which would prevent knowledgeable users from figuring out what the problem is). >+<!ENTITY fileNotFound.longDesc " >+ [li]Check the file name for for capitalization or other typing errors.[/li] s/for for/for/ >+ [li]Be sure that you have the required access to see the file at this >+ address.[/li] This sounds odd to me; what cause of the error does this describe? If I knew what this was describing I'd try to come up with something, but I'm at a loss for how permissions can trigger this. (My guess that trying to read, say, ~root/.bashrc as non-root would trigger this is wrong according to one response from a user in #firefox.) >+<!ENTITY generic.title "Oops"> Maybe add an exclamation mark at the end there? It feels like the title's just sort of "hanging" otherwise. :-) >+<!ENTITY generic.longDesc " >+[p]Firefox has experienced a problem, and wasn't able to complete your request. >+[/p] >+"> If this is actually what's used (it feels very rough, but I don't have suggestions at the moment), please remove the comma after "problem" -- you've got a comma splice without the change. >+<!ENTITY malformedURI.title "The address isn't valid"> >+ [li]Web addresses are usually written like [b]http://www.example.com[/b][/li] This might be just me, but I'd prefer if you had an ending slash there after <http://www.example.com>. >+<!ENTITY netOffline.title "Offline mode"> >+<!ENTITY netOffline.longDesc " >+[p]Firefox is currently in offline mode and is unable to browse the Web.[/p] Perhaps use "can't" instead of "is unable to" to reduce unnecessary wordiness? >+ [li]Uncheck "Work Offline" in the "File" menu to take the browser out of >+ offline mode, then try again.[/li] Please insert "and" before "then", and if we're making this Firefox-specific change "the browser" to "Firefox". >+<!ENTITY netTimeout.title "The connection has timed out"> >+[p]Firefox got tired of waiting to hear back from the server at %S.[/p] How about: "The server at %S is taking too long to respond to Firefox's request." I don't really like having "request" in there, tho -- can anyone think of something better to put in place of it? This still feels sort of awkward, so there's probably a better string to use here if someone can find it. >+<!ENTITY proxyConnectFailure.title "The proxy server is refusing connections"> >+ [li]Contact the network administrator to make sure the proxy server >+ is working.[/li] I'd suggest changing "the network administrator" to "your network administrator" to be more friendly. Another possible option might be to say "the person who runs your network" to use fewer geeky terms, but that's probably just me underestimating the average user. After all, I think Microsoft uses it in their software. >+<!ENTITY proxyResolveFailure.title "Unable to find the proxy server"> >+ [li]Check to make sure you computer has a working network connection.[/li] s/you/your/ >+<!ENTITY unknownSocketType.title "Unexpected response from server"> >+<!ENTITY unknownSocketType.longDesc " >+[p]The server at %S responded to the request in an unexpected way, and >+ Firefox cannot continue.[/p] "cannot continue" almost sounds like Firefox crashed, which clearly isn't what's happened. Would this be any better? (I almost think it isn't, but I'm really not all that sure.) The server at %S responded to the request in an unexpected way, and Firefox doesn't know how to respond to the server. (I considered posting these changes as a patch, but it's probably better to have one person do all the consolidation of suggestions to better keep things under control.)

(In reply to comment #31; some portions removed) > >+<!ENTITY deniedPortAccess.title "This port is restricted"> > >+<!ENTITY deniedPortAccess.longDesc " > >+[p]This address (%S) specifies a network port which is normally used for > >+ purposes other than Web browsing. Firefox has canceled the request for your > >+ protection.[/p] > >+"> > > Realistically, can we expect the average user to know what a network port is? > I'm not sure what the fix is here, because we can't really obfuscate here > (which would prevent knowledgeable users from figuring out what the problem > is). I don't really know that we need to change this at all. The facts are there and as you said we can't get rid of any of the important information. We've stated that it's related to the address(1), isn't normal for Web browsing(2), and that the action was canceled for security/"your protection"(3). A normal user should get the hint after #1-3. If they want to learn what a port is, they can look it up. Aside from giving a tutorial on URLs, I don't know if there's much we can do on an error page. IMHO, it's fine as-is. > >+<!ENTITY fileNotFound.longDesc " > >+ [li]Be sure that you have the required access to see the file at this > >+ address.[/li] > > This sounds odd to me; what cause of the error does this describe? If I knew > what this was describing I'd try to come up with something, but I'm at a loss > for how permissions can trigger this. (My guess that trying to read, say, > ~root/.bashrc as non-root would trigger this is wrong according to one response > from a user in #firefox.) FYI, the mention of permissions comes from the original netError.dtd that's been going out with the 1.0.x builds. I know I can force this event by trying to access a drive/partition or network path that doesn't exist. An access-restricted network path might act the same way (haven't personally verified). > >+<!ENTITY generic.title "Oops"> > > Maybe add an exclamation mark at the end there? It feels like the title's just > sort of "hanging" otherwise. :-) Agreed. > >+<!ENTITY malformedURI.title "The address isn't valid"> > > >+ [li]Web addresses are usually written like [b]http://www.example.com[/b][/li] > > This might be just me, but I'd prefer if you had an ending slash there after > <http://www.example.com>. What about changing the title to "This address isn't valid" as well? > >+<!ENTITY netTimeout.title "The connection has timed out"> > > >+[p]Firefox got tired of waiting to hear back from the server at %S.[/p] > > How about: > > "The server at %S is taking too long to respond to Firefox's request." > > I don't really like having "request" in there, tho -- can anyone think of > something better to put in place of it? This still feels sort of awkward, so > there's probably a better string to use here if someone can find it. Simple... make it shorter: "The server at %S is taking too long to respond." > >+<!ENTITY unknownSocketType.title "Unexpected response from server"> > >+<!ENTITY unknownSocketType.longDesc " > >+[p]The server at %S responded to the request in an unexpected way, and > >+ Firefox cannot continue.[/p] > > "cannot continue" almost sounds like Firefox crashed, which clearly isn't > what's happened. Would this be any better? (I almost think it isn't, but I'm > really not all that sure.) > > The server at %S responded to the request in an unexpected way, and Firefox > doesn't know how to respond to the server. Or: "Firefox doesn't know how to communicate with the server at %S. Its response was not what Firefox expected." No issues w/ the other suggestions; sounds good to me. :-)

Attaching a patch that makes the following changes, and has pretty-printing of the DTD removed so that it's testable: >Why not "your computer's" instead of "the computer's"? Agreed. > Perhaps we should split it out into a new, internal entity > that's used in the creation of these so as to have less duplication. Good idea, but I'm not quite sure what's required to get that done, so I've skipped that step for now. Feel free to modify as appropriate :) > Realistically, can we expect the average user to know what a network port is? I don't think so, no. We ran into this problem with protocol, as well, and it's a nasty tradeoff between obfuscation and simplification as you point out. I think the right answer here is to make the title simple ("This address is restricted") and the follow up text informative ("%S uses a network port which is normally used for purposes other than Web browsing. Firefox has canceled the request for your protection.") > s/for for/for/ Fixed, thanks. > This sounds odd to me; what cause of the error does this describe? To be honest, I'm not sure myself, and was just editing the error message that came before :) I'm happy to remove it as a suggested thing to check. > Maybe add an exclamation mark at the end there? A period, I think. Don't want to seem to excited about it. > If this is actually what's used (it feels very rough, but I don't have > suggestions at the moment), please remove the comma after "problem" -- > you've got a comma splice without the change. My least favourite error message, and I'm not even sure what error cases end up leaving us in this state. Removed the comma splice, and tried changing the text to: "Firefox can't load this page for some reason." I'd feel way more comfortable about this if I knew how we got here, and what appstring would be shown. Anyone know more about this error case? > This might be just me, but I'd prefer if you had an ending slash there after > <http://www.example.com>. Both changes made. I'd also like to make the bold bits bold and red or something, but am unsure if I can just shove in any ol' colour tags in these entities. > Perhaps use "can't" instead of "is unable to" to reduce unnecessary wordiness? Done. I need to grow a backbone about my decision to use contractions. :) > Simple... make it shorter: > "The server at %S is taking too long to respond." Done. > I'd suggest changing "the network administrator" to "your network > administrator" to be more friendly. Done. > s/you/your/ Done. > The server at %S responded to the request in an unexpected way, and Firefox > doesn't know how to respond to the server. I asked darin, and he said that this error actually only occurs in a very small percentage of cases, normally when a user doesn't have the PSM component (https) installed. I've updated the DTD and appstrings to reflect that: appstring = "Firefox doesn't know how to communicate with the server at %S." longDesc = "[ul][li]Check to make sure your system has the Personal Security Manager installed.[/li][li]This might be due to a non-standard configuration on the server.[/li][/ul]"

Changed "unable to connect to any addresses" to "unable to load any pages" so that it made sense in english :) Requesting a review, as I'd really like to land this in time to get it translated and stuff.

Comment on attachment 192473 [details] [diff] [review] v7 changes to appstrings and neterror (for review) Oops. Forgot that I'm hardcoding all the brandnames here. I knew it was too good to be true!

(In reply to comment #33) > > Perhaps we should split it out into a new, internal entity > > that's used in the creation of these so as to have less duplication. > > Good idea, but I'm not quite sure what's required to get that done, so I've > skipped that step for now. Feel free to modify as appropriate :) It's getting late and I'm running short on time, so I'll just describe the steps to do this instead. Say you have the following entities defined: <!ENTITY foo "[p]That port's evil.[/p][ul][li]Generic info[/li][/ul]"> <!ENTITY bar "[p]What's that protocol?[/p][ul][li]Generic info[/li][/ul]"> <!ENTITY baz "[p]You don't have PSM.[/p][ul][li]Generic info[/li][/ul]"> What you want is to only have to define "[ul][li]Generic info[/li][/ul]" once. To do so, create a new entity like so: <!ENTITY shared "[ul][li]Generic info[/li][/ul]"> You also probably want to add an explanatory localization note (formatted like <http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/preferences/fonts.dtd#21>). Then use the entity inside the definitions for the other entities, like so: <!ENTITY shared "[ul][li]Generic info[/li][/ul]"> <!ENTITY foo "[p]That port's evil.[/p]&shared;"> <!ENTITY bar "[p]What's that protocol?[/p]&shared;"> <!ENTITY baz "[p]You don't have PSM.[/p]&shared;"> I don't remember whether the entity must be defined before it's used (as shown above) or not (the situation if the "shared" line could be legally moved below the "baz" line), so you'll have to test this to see for yourself. Personally, I'd prefer the shared entity be added after all the other entity pairs in netError.dtd so as to keep the organization the same, but it's not really a big issue if you have to do it as demonstrated above. > > This sounds odd to me; what cause of the error does this describe? > > To be honest, I'm not sure myself, and was just editing the error message that > came before :) I'm happy to remove it as a suggested thing to check. Yeah, I think removing it's a good idea unless some necko gurus can tell us why it's there; less is more. > > Maybe add an exclamation mark at the end there? > > A period, I think. Don't want to seem to excited about it. It's not so much "excited" as that you don't hear people say "oops" in a level voice; there's a guilty tone, some sort of emphasis, or some such thing beyond just the sound of the word. Using nothing and using a period both suggest a level voice here, whereas an exclamation mark conveys a much more natural tone. It's one character, tho, so let it go if you must. > I'd also like to make the bold bits bold and red or something, but am unsure > if I can just shove in any ol' colour tags in these entities. Theoretically you should be able to do so, although keep in mind how things could look with an arbitrary user-selected theme with, say, a red background. (To take this into account you'd have to modify five additional skin files in toolkit/ and themes/.) Personally, I'd suggest just sticking with <strong/> and leave its default style alone; don't overdo it.

-<!ENTITY deniedPortAccess.title "Port Restricted for Security Reasons"> -<!ENTITY deniedPortAccess.longDesc "[p]The requested address specified a port (e.g. [q]mozilla.org:80[/q] for port 80 on mozilla.org) normally used for purposes [em]other[/em] than Web browsing. The browser has canceled the request for your protection and security.[/p]"> +<!ENTITY deniedPortAccess.title "This address is restricted"> +<!ENTITY deniedPortAccess.longDesc ""> Empty longDesc?

(In reply to comment #37) > Empty longDesc? Yeah. There's not a long to say there in terms of suggesting alternatives. The appstring gives more detail about what went wrong (and echoes the URL), but after that, what can you say?

Comment on attachment 192473 [details] [diff] [review] v7 changes to appstrings and neterror (for review) >+<!ENTITY netOffline.title "Offline mode"> >+<!ENTITY netOffline.longDesc "[li]Uncheck Work Offline in the File menu to take the browser out of offline mode, then try again.[/li][/ul]"> Incidentally, it looks like netOffline wouldn't work because tags in &netOffline.longDesc; aren't balanced. I don't know exactly how it would fail because of the current innerHTML hack being used. Also of note is the fact that bug 302729 is reviewed and approved for checkin. This means that we should be able to use sane-looking entity values with normal, unhackified HTML! As soon as a patch for this bug is approved and ready we need to coordinate with that bug so that both this bug and that bug can be fixed close to simultaneously; if we don't check them in pretty close to each other we'll have broken-looking error pages. I'll post a new version of the latest patch here that addresses the tag imbalance and the sane-looking HTML issues in a second. Make sure to read the instructions that will accompany the patch so you know how to test it, or else you'll have broken error pages.

I fixed the tag imbalance, changed a few instances of the non-semantic <b/> element to <strong/> (which I apparently overlooked earlier and should have mentioned then), and converted the whole thing to be pretty. I also added the shared entity I suggested earlier. You must apply attachment 192114 [details] [diff] [review] to your tree in order to test this patch. If you don't do this, the patch *will* fail to work properly. You have been warned.

*** Bug 305634 has been marked as a duplicate of this bug. ***

I asked dria to look at the strings, and she suggested two small changes: - add quotes around "Work Offline" (I'd removed them because I forgot to use the &quot; entity - oops) - change the appstring for proxyFailedConnect I think we're actually finally oh-my-god done with the messages. Also, looking through them, I noticed that most of the references to "Firefox" were in the appstrings, not in the DTD. I think it'd be totally possible to make it so that *all* of the references to "Firefox" were in appstrings, especially if that meant that we lost our dependency on bug 302309, but I'm not sure that it would. Would it?

1) I think the patch won't apply cleanly to either current trunk or branch, as we already have changed all [] to <> there. 2) No file out side a branding/ bundle should hardcode an app name, wherever in chrome it is, esp. not if it's in core code that is shared with other apps (and if that file in mozilla/dom/locales/en-US/chrome/ is not, then we have a major bug by itself). We should _always_ refer to brandShortName / brandFullName everywhere outside branding bundles. This is even important in app-specific code as we're doing things like calling testing releases differently than the product name, and in that case it should say "Deer Park" or whatever automatically even for those strings.

Yes, well, that's why we need bug 302729 (pretty HTML formatting for DTDs) and bug 302309 (to enable the &brandShortName; entity) to land before this one, but thanks for the reminder!

(In reply to comment #44) > Yes, well, that's why we need bug 302729 (pretty HTML formatting for DTDs) and > bug 302309 (to enable the &brandShortName; entity) to land before this one, but > thanks for the reminder! It seems you don't have your bugmail set up to receive notifications of changes in bugs depending or dependent upon this one; bug 302729 was fixed a couple days ago on both the branch and the trunk, so there's no need to test with another patch in addition to the one here.

Thanks Jeff; I saw it had landed on trunk, but didn't know it had hit branch. I must talk to BugZilla about that! :) Since I'm not sure that bug 302309 will land in time for Firefox 1.5, I've opened (as per mconnor's suggestion) bug 305998 as a band-aid solution to try and at least get the messages in as an override for Firefox 1.5 only, and then we can get the product name stuff sorted out for Gecko 1.9 or whatever. (if it sounds like I only 1/2 understand what I'm saying, there's a reason!)

Requesting that this bug be -'d for 1.8b4 since bug 305998 has come up with a solution that will work for FFx 1.5, but be kept open, as this should definitely be resolved for trunk / future :)

getting remaining 1.5 work under bug 305998

(I assume the whiteboard status is now obsolete.)

Please note that attachment 196134 [details] [diff] [review] from bug 184144 was just checked in on trunk, in case you'd like to further review the wording for the new error (contentEncodingError).

Do we have any update for this bug? There is attached a patch without a review request for ages. It this bug still valid?

Beltzner, what is the status of this bug? It contains a patch from you, which is four years old. Can this bug be closed?