157004 - Use original URL in history and URL bar when an error page is generated (show failed url)

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Adam Lock]

When error page support is enabled (see bug 28586), the error page url is
displayed in the location bar of the browser. This needs to be supressed somehow
and the page should not appear in the session history either.

Comment 1

[Radha on family leave (not reading bugmail)]

I thought the page would not appear in session history, since
LOAD_BYPASS_HISTORY flags are used to load it.  Is there a bug in it?

Comment 2

[Adam Lock]

I think there is. I haven't looked too closely to see what I'm doing wrong, but
the error page is definitely being added to the session history. 

Comment 3

[Adam Lock]

Actually, I think I can see the issue - I specify LOAD_RELOAD_BYPASS_CACHE, not
LOAD_FLAGS_BYPASS_CACHE. I'll just confirm that is the issue.

Comment 4

[Adam Lock]

Changing it to LOAD_FLAGS_BYPASS_CACHE didn't make any difference. I'll have to
look at this a bit more carefully tomorrow morning.

Comment 5

[Radha on family leave (not reading bugmail)]

I thin you need nsIWebNavigation::LOAD_FLAGS_BYPASS_HISTORY(not BYPASS_CACHE)
which gets mapped to LOAD_BYPASS_HISTORY.

Comment 6

[Adam Lock]

Attachment: Patch

Thanks Radha that fixes it. That flag combo didn't map onto a load type so it
took some wacky route through loadURI.

1-line patch fixes the flags. sr/r?

Comment 7

[Radha on family leave (not reading bugmail)]

Comment on attachment 91103 [details] [diff] [review]
Patch

r=radha presuming, this completely eliminates the error page from getting into
session history.

Comment 8

[Adam Lock]

Yes it does.

Comment 9

[rpotts (gone)]

Comment on attachment 91103 [details] [diff] [review]
Patch

sr=[e-mail]

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 91103 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.

Comment 11

[Adam Lock]

First patch is checked in

Comment 12

[Adam Lock]

Attachment: Work in progress

This patch is *almost* there but has a few problems. It works by storing the
bad URI in an mErrorURI variable and firing that in the location change event
and also adding it to the session history. That means when you browse to a
nonexistent address you'll see that address in the error bar but the content
will be the error xhtml. The only time you'll see the error page's full URI is
if there url causing the error is malformed and *can't* be turned into a URI
object.

I'm still having some session history problems. I've changed LoadErrorPage so
it tries to figure out its load flags from the mLoadType that was presumably
set when the load was initiated. This allows the flags to be correct whether it
is being loaded from session history or normal. It's not replacing the pages
properly so entries are being lost in the session history. Radha do you know
what I'm missing something here?

Comment 13

[Radha on family leave (not reading bugmail)]

Adam, From the comments  you have made above, it looks like you want to preserve
the loadType with which the url was originally loaded (thro' SH or LOAD_REPLACE
or BYPASS_HISTORY or whatever ..) But you are checking for only LOAD_REPLACE as
the special condition and not really passing the current loadType to LoadURI().
If the  original loadType was anything other than LOAD_REPLACE, the patch will
pass FLAGS_NONE  and therefore, LOADURI() will assume a LOAD_NORMAL. Is this
what you really wanted? 

Comment 14

[resigned]

Possibly, my new bug of: <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=159537">159537</a> should be
marked as a dupe of this one,

 ... except that the new bug concentrates purely on the URL-overwriting aspect,
and happens irrespective of whether error-page's are being used.

Comment 15

[Adam Lock]

Attachment: Work in progress

I've updated the code to call the second form of LoadURI in nsDocShell. This
means I avoid trying to turn mLoadType back into load flags and can set the
load type directly on a load info object. It still doesn't work though, the
session history is still misbehaving when I go back and forth when there are
error pages in it.

I'll have to examine this more when I get back from holiday.

Comment 16

[Radha on family leave (not reading bugmail)]

Adam, I'm not sure I clearly understand what you are trying to do. Can you send
 me your steps to reproduce the problem and I will take a look by applying your
latest patch.   Thanks.

Comment 17

[Jeremy M. Dolan]

Filed Bug 160548 on history not advancing. Error pages shouldn't be in history,
but it still needs to "advance" so back and go menus work properly. Better
description and steps to reproduce in that bug.

Comment 18

[Aleksey Nogin]

IMHO, while the error page URL should not be in the history, the *original* URL
that caused the error *should* be in history. This should take care of
"advancing" correctly and this should make it possible to come back later to a
page that fails to load and to try loading it again. This also should work in a
way such that pressing "reload" on an error page would re-try the original page.

P.S. BTW, what I describe is the behaviour that you get when using a proxy
(Squid, for example) that would just report all the errors as the error page
(but will still keep the original URL). It works really nice with history,
"reload", etc and I think Mozilla should act the same way.

Comment 19

[Tom Mraz]

I would like to change the summary to:

Add error pages to history/URL bar with original URL

This would be the (IMHO correct) behavior which is described in the previous
comment.

Comment 20

[Alfonso Martinez]

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

Comment 21

[Adam Lock]

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

Comment 22

[Adam Lock]

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

Comment 23

[Asa Dotzler [:asa]]

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

Comment 24

[[e-mail]]

IMO this should get higher severety, because it essentially makes the 
error page unusable: one of the more often-encountered errors is simply
a mistyped url - and even more so if the URL is long and complicated.
Unless the url is preserved when displaying the error page, it is impossible
to correct the typing error and you have to reenter everything again.
IMO that is data loss.

Comment 25

[Jeremy M. Dolan]

Workaround for johann's issue:

Fix the address in the long error page URL (it will be escaped, but it's usually
not a problem), hit enter to load the new error page for the fixed typo, and
then click "Try again" to actually load the new page.  A bit of a pain, but
usually better than starting over.

Comment 26

[Stefan Huszics]

> IMO this should get higher severety, because it essentially makes the 
error page unusable: one of the more often-encountered errors is simply
a mistyped url

I agree. We have a thread over at Mozillazine forums (
http://www.mozillazine.org/forums/viewtopic.php?t=3463 ) where we make
suggestions for error pages, and this bug litteraly forces us to add an ugly
<input> form element to allow to make the pages usable.

This is an example of a concept page with an <input> element
http://hem.bredband.net/b103277/errorpage/indexform2.html

With this bug fixed the IMO biggest stumbeling block in making a nice looking
error page is removed.
It would be really nice if this bug would be fixed sooner rather then later. :)

Comment 27

[Adam Lock]

Attachment: Work in progress 2

Patch updated to latest docshell. 

Radha, I'm still having problems with session history and would be grateful if
you could take a look.

Superficially it works fine, but it still exhibits the same problems with
session history, that is to say use back and forward to find an error page, hit
reload and it uses the wrong session history entry.

Steps to reproduce.

1. Apply patch, build
2. Edit user.js in the mfcembed user profile and set
browser.xul.error_pages.enabled to true
3. Run mfcembed.exe
4. Load www.mozilla.org
5. Load www.dlsfjlksdjflsdkjflsdjf.com (resulting in error page)
6. Load www.gnu.org

Back and forward through session history work, but if you go to the error page
and hit reload it will either pick up www.mozilla.org or www.gnu.org depending
on which direction you came to it from.

Note until bug 193033 is fixed, you'll need to do some surgery to
nsChromeProtocolHandler.cpp to skip around some bustage.

Comment 28

[Samir Gehani]

adt: nsbeta1-

Comment 29

[David Fraser]

So far all the discussion, patches on this bug focus on the history part, not
the URL bar part.
I think the URL bar part is equally important - should another bug be opened for
this, or if not, what needs to be done to fix it?

Comment 30

[Mike Connor [:mconnor]]

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

Comment 31

[Mike Pinkerton (not reading bugmail)]

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

Comment 32

[Simon Paquet [:sipaq]]

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

Comment 33

[Michael Lefevre]

could be kind of tricky to have this block 1.6a without the aid of a time machine.

can't see it would be a blocker for the others, given that it's not been a
blocker for the previous releases, and that error pages aren't enabled by
default, but that's up to drivers.

Comment 34

[Grey Nicholson (they/them)]

How about a 1.7a target?

Comment 35

[Asa Dotzler [:asa]]

Not going to block 1.6 for this. Who can own this? Bryner, jst, danm?

Comment 36

[Jens Bannmann]

I don't know if this will help, but one might take a look at the "Show Failed
URL" extension - see http://forums.mozillazine.org/viewtopic.php?t=37478 - which
addresses the URL bar part of this issue.

Comment 37

[alanjstr]

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

Comment 38

[alanjstr]

Show failed URL, http://www.pikey.me.uk/mozilla/#sfu , works great.  If we want
to split the URL bar piece seperately, then, reopen bug 227146.

Comment 39

[Dan M]

Pike's extension is an improvement in some ways but it also has some problems.
The session history issue remains unsolved and worse, it's unstable. Though
session history appears to clean itself up if the user clicks "Try again" at the
right point.

Sigh. We were going in a different direction with this at one time but it's safe
to say that effort has stalled. Perhaps it's time to take Pike's lead.

Note the Mozilla-not-Phoenix browser has some strange intermediate behaviour.
Yay, two official browser apps.

Comment 40

[Bill Mason]

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

Comment 41

[chris hofmann]

think we will have this by 1.7 beta?

Comment 42

[R.K.Aa.]

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

Comment 43

[Michael Hendy (Hendikins)]

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

Comment 44

[PikeUK]

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

Comment 45

[Bill Mason]

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

Comment 46

[Doug Halamay]

Any chance this can be fixed for FF1.0RC1?  It's a real pain.

Comment 47

[chris hofmann]

danm, want to take on this bug?

Comment 48

[Max Waterman]

I am pleased to see that opening a link in a new tab in firefox now fills in the
URL field, so I can reload (by click-return in the URL field), but the problem
still remains when you open a link in a new window.

Comment 49

[Bill Mason]

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

Comment 50

[Christian :Biesinger (don't email me, ping me on IRC)]

this could probably be fixed by setting LOAD_BACKGROUND for the error page (thus
not triggering loadgroup notifications), and by not firing OnLocationChange for
the error page, which should be easy to do, since it's the docshell that fires it.

Comment 51

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: alternative patch

oops. hadn't noticed there was a previous patch here.

Anyway, this is an alternative. it just fixes the urlbar though.

I made LOAD_ERROR_PAGE here equivalent to LOAD_FLAGS_BYPASS_HISTORY; probably
not all of these changes are needed

Comment 52

[Darin Fisher]

Comment on attachment 164200 [details] [diff] [review]
alternative patch

shouldn't this set LOAD_BACKGROUND on the error page channel?

Comment 53

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #52)
> shouldn't this set LOAD_BACKGROUND on the error page channel?

yeah, in an ideal world it should. but that causes onload not to fire, which the
error page does not really like.

Comment 54

[Darin Fisher]

> yeah, in an ideal world it should. but that causes onload not to fire, which the
> error page does not really like.

ok, fair enough.

Comment 55

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: alternative patch v2

this also fixes problems with session history. all of reload, back and forward
now seem to work correctly.

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 164233 [details] [diff] [review]
alternative patch v2

this contains parts of the patch to remove *WithConversion from docshell... no
good way to disentangle that one. I'll just check that in with this patch.

Comment 57

[Christian :Biesinger (don't email me, ping me on IRC)]

oh, and this _does_ use LOAD_BACKGROUND now, with some fixes to the html.

Comment 58

[Max Waterman]

does it work with new tabs *and* new windows?

currently, if I open a link in a new tab, it seems to always get the URL even if
an error occurs (usually a dns failure), but if I open it in a new window, there
is no URL.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20041001
Firefox/0.10.1

Comment 59

[Christian :Biesinger (don't email me, ping me on IRC)]

Max: that is a different bug. this one is about error pages, which are not
enabled unless you set a hidden pref.

Comment 60

[Max Waterman]

hrm, ok. perhaps the summary should be adjusted - it doesn't seem to match the
'description'.

Comment 61

[Asa Dotzler [:asa]]

not gonna happen for firefox 1.0

Comment 62

[Phil Ringnalda (:philor)]

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

Comment 63

[Christian :Biesinger (don't email me, ping me on IRC)]

ok, so some things that still need fixing with the patch:
- javascript:histoy.reload() shows the wrong URI and presumably loaded the wrong
URI too

- pressing escape in urlbar shows the chrome: uri
- switching to a tab showing an error page that was loaded in background shows
chrome uri in urlbar

I'll probably attach a v3 patch unless bz reviews first...

Comment 64

[Boris Zbarsky [:bzbarsky]]

If you want to do another rev, please go for it... I'm still trying to get to
review requests that were made a month ago.  :(

Comment 65

[nrlz]

I came to post this bug but found this page. I've read all the comments but some
of them are technical which I don't understand so I'm just gonna post my
suggestions. (I apologize if they are covered already.):

1) correct URL should be placed in address bar.
So I can correct it and press enter again. e.g., yahoo.ocm => yahoo.com

2) Pressing "Reload" on the navigation toolbar should attempt to reload original
page (not the chrome one). Same should also work if I right click on Tab and
click "Reload Tab".
If it was a temporary network problem. I can usually reload it and it will work. 

3) It should give a better indication of error if a tab couldn't load. This
could either be implemented with sound (could be the same as the findasyoutype
error beep) or the tab favicon/siteicon should have an exclamation mark.

4) Current "Try Again" link should have a larger text size so I can click on it
easier. The description for "www.yahoo.ocm could not be found ....." should have
the "www.yahoo.ocm" part in bold or bigger so I can read it faster and
differentiate it from the rest of the sentence.

Comment 66

[nrlz]

Oh and one more thing:

5) If the error page was due to a server error after a form submission. Pressing
"Try Again" or the "Reload" toolbar button should resubmit the form.

That way I don't lose all my typed data inside that form. (And of course it
should ask me "Do you want to submit again...blah?" incase it is a shopping cart
and I don't want to submit again.)

Comment 67

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #65)
> 1) correct URL should be placed in address bar.
> So I can correct it and press enter again. e.g., yahoo.ocm => yahoo.com

Right - that's the main point of this bug; the patch fixes it (except for
malformed uris - this one's hard to fix)

> 2) Pressing "Reload" on the navigation toolbar should attempt to reload original
> page (not the chrome one). Same should also work if I right click on Tab and
> click "Reload Tab".
> If it was a temporary network problem. I can usually reload it and it will work. 

Yes, that's what the patch does; I haven't thought of the second part yet,
thanks for the reminder to test it.

> 3) It should give a better indication of error if a tab couldn't load. This
> could either be implemented with sound (could be the same as the findasyoutype
> error beep) or the tab favicon/siteicon should have an exclamation mark.

can we do that in a different bug? this one's about bugs in the error pages
implementation, not general feedback when a page doesn't load...

> 4) Current "Try Again" link should have a larger text size so I can click on it
> easier. The description for "www.yahoo.ocm could not be found ....." should have
> the "www.yahoo.ocm" part in bold or bigger so I can read it faster and
> differentiate it from the rest of the sentence.

I personally will probably not fix any design issues with the error pages; so,
can this, too, be done in a different bug? might be covered by bug 170216.

(In reply to comment #66)
> 5) If the error page was due to a server error after a form submission. Pressing
> "Try Again" or the "Reload" toolbar button should resubmit the form.

that's bug 237244

Comment 68

[:Gavin Sharp [email: [e-mail]]]

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

Comment 69

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #63)
> ok, so some things that still need fixing with the patch:
> - javascript:histoy.reload() shows the wrong URI and presumably loaded the wrong
> URI too

Looks like I must have meant "location.reload()", because history.reload()
doesn't seem to exist...

> - pressing escape in urlbar shows the chrome: uri
> - switching to a tab showing an error page that was loaded in background shows
> chrome uri in urlbar

have a patch where this is fixed; going to attach it in a second. fix is not to
set mCurrentURI while doing an error page load. since that means
document.location.href will not be the chrome: uri, but instead the real page
uri, I had to switch netError.js to use document.documentURI for that.

Comment 70

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: alternative patch v3

Comment 71

[Christian :Biesinger (don't email me, ping me on IRC)]

>2) Pressing "Reload" on the navigation toolbar should attempt to reload original
>page (not the chrome one). Same should also work if I right click on Tab and
>click "Reload Tab".

I verified that my latest patch here fixes both of this.

note to self: Need to come up with a solution for malformed URIs

Comment 72

[:Gavin Sharp [email: [e-mail]]]

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

Comment 73

[:Gavin Sharp [email: [e-mail]]]

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

Comment 74

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 168419 [details] [diff] [review]
alternative patch v3

>+nsDocShell::LoadErrorPage(nsIURI *aURI, const PRUnichar *aURL,

>+               ("nsDocShell[%p]::LoadErrorPage(%s, %s, {...}, [%s])\n", this,

Put \" around the first two %s things?	It'll make the output nicer....  (on a
side note, we need to add a lot more nspr logging to docshell, methinks).

>nsDocShell::OnNewURI(nsIURI * aURI, nsIChannel * aChannel,

>+               ("nsDocShell[%p]::OnNewURI(%s, [%s], 0x%x)\n", this, spec.get(),

Again, put \" around the first %s, please.

Same in AddToSessionHistory.

>+#define LOAD_FLAGS_ERROR_PAGE 0x8000U

Add a comment that this should be bigger than all flags on nsIWebNavigation?

>+    LOAD_ERROR_PAGE = MAKE_LOAD_TYPE(nsIDocShell::LOAD_CMD_NORMAL, LOAD_FLAGS_ERROR_PAGE),

Add some documentation here about what this load type means?

>Index: resources/content/netError.js

Add documentation explaining why this method of getting the URI is being used? 
And maybe document the relevant apis with an explanation of how the values
differ?

 >Index: resources/content/netError.xhtml

Document why this needs to be inline script instead of an onload handler, lest
someone "fix" it back?

r=bzbarsky with those changes.	I really wish our load flag system involved
less "magic".... :(

Comment 75

[Brian Polidoro]

This missed 1.8a6 will it land for 1.8b?

Comment 76

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: alternative patch v4

- updated to trunk (mainly moved the LOAD_ERROR_PAGE check to the new
two-argument SetCurrentURI function)
- made changes requested by bz

as for:
>And maybe document the relevant apis with an explanation of how the values
>differ?

I don't think I want to change nsIDOM* interfaces to mention error pages or
docshells, and I can't come up with a description of the difference without
that...

Comment 77

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 172771 [details] [diff] [review]
alternative patch v4

> I don't think I want to change nsIDOM* interfaces to mention error pages or
> docshells

It think doing it for DOMLocation is reasonable.  It's a quirky DOM0 api, and
the quirkiness should be made clear.

In particular, perhaps something like "This is guaranteed to be the same URI as
shown in the location bar, which may not be the same as the documentURI of the
document"?

r=bzbarsky

Comment 78

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch v5 (checked in, except nsIDOMLocation)

ok, made that change

Comment 79

[:Gavin Sharp [email: [e-mail]]]

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

Comment 80

[Darin Fisher]

Comment on attachment 172838 [details] [diff] [review]
patch v5 (checked in, except nsIDOMLocation)

sr=darin, but i'm not so sure about the comment in nsIDOMLocation.  you should
really run that by jst first.  my concern: is nsIDOMLocation strictly about the
location bar in a browser?  is the comment being too specific?

Comment 81

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 172838 [details] [diff] [review]
patch v5 (checked in, except nsIDOMLocation)

OK. I checked this patch in, except the nsIDOMLocation.idl part

Comment 82

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: nsIDOMLocation patch

this patch changes nsIDOMLocation.idl as requested by bz in comment 77; also
note comment 80

Comment 83

[Christian :Biesinger (don't email me, ping me on IRC)]

hm, I found a (small) problem with the patch, I think... with it, we load error
pages LOAD_BACKGROUND (note comment 52); but this means that we won't fire
onStateChange (right?) - accessibility does want to get that, though...
(http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsDocAccessible.cpp#724,
http://lxr.mozilla.org/seamonkey/source/accessible/src/base/nsAccessibilityService.cpp#152)

Comment 84

[Johnny Stenback (:jst)]

Comment on attachment 172943 [details] [diff] [review]
nsIDOMLocation patch

r+sr=jst

Comment 85

[CBWhiz]

With the patch in (testing build 2005-02-04), I can confirm that the address bar
is correctly retained as the invalid URL's site. However, the following oddity
occurs:

0. have xul error pages turned on
1. Visit a bad url, say www.ldfghkljhfewlufhlurfhlwekj.com
2. You receive the XUL error page, as expected, and the invalid domain is in the
location bar, as expected.
3. Click "Try Again"
4. You receive the XUL error page, as expected, but the error page's URL is not
in the location bar.
5. Click "Try Again"
6. You receive the XUL error page, as expected, but the origonal page (not the
error page)'s URL is in the location bar.

Continuously clicking "try again" will have the location bar alternate between
the origonal failed url, and th eerror page's url.

Comment 86

[Christian :Biesinger (don't email me, ping me on IRC)]

try again currently sucks. I'll fix it in the "try again does not report form
data" bug.

nsIDOMLocation patch checked in
Checking in dom/public/idl/base/nsIDOMLocation.idl;
/cvsroot/mozilla/dom/public/idl/base/nsIDOMLocation.idl,v  <--  nsIDOMLocation.idl
new revision: 1.7; previous revision: 1.6
done

leaving open for comment 83...

Comment 87

[alanjstr]

(In reply to comment #86)
> try again currently sucks. I'll fix it in the "try again does not report form
> data" bug.

Is that bug 215753?

Comment 88

[Aaron Leventhal]

It's on my list to look at what this does to the accessibility code.

Comment 89

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #87)
> Is that bug 215753?

actually no, I weren't aware of that bug. I meant bug 237244.

Comment 90

[Jesse Ruderman]

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

Comment 91

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Minusing blocking request since 1.8b1 is about to ship and it's pretty near
impossible to tell from skimming the bug what the problem *currently* is (since
the summary disagrees with comment 85, which says that the bug described in the
summary is fixed).

Comment 92

[Christian :Biesinger (don't email me, ping me on IRC)]

filed bug 285055 on comment 83. marking this one fixed.

Comment 93

[Jesse Ruderman]

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

Comment 94

[Jesse Ruderman]

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

Comment 95

[Steve England [:stevee]]

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

Comment 96

[Steve England [:stevee]]

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

Comment 97

[djpohly]

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

Comment 98

[Dave Townsend [:mossop]]

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