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

RESOLVED FIXED in mozilla1.8alpha6

Status

()

defect
RESOLVED FIXED
17 years ago
13 years ago

People

(Reporter: adamlock, Assigned: Biesinger)

Tracking

(Blocks 2 bugs)

Trunk
mozilla1.8alpha6
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.8b -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-P0])

Attachments

(5 attachments, 5 obsolete attachments)

(Reporter)

Description

17 years ago
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.
(Reporter)

Updated

17 years ago
Blocks: errorpages
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?
(Reporter)

Comment 2

17 years ago
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. 
(Reporter)

Comment 3

17 years ago
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.
(Reporter)

Comment 4

17 years ago
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.
I thin you need nsIWebNavigation::LOAD_FLAGS_BYPASS_HISTORY(not BYPASS_CACHE)
which gets mapped to LOAD_BYPASS_HISTORY.
(Reporter)

Comment 6

17 years ago
Posted patch PatchSplinter Review
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 on attachment 91103 [details] [diff] [review]
Patch

r=radha presuming, this completely eliminates the error page from getting into
session history.
Attachment #91103 - Flags: review+
(Reporter)

Comment 8

17 years ago
Yes it does.
Comment on attachment 91103 [details] [diff] [review]
Patch

a=asa (on behalf of drivers) for checkin to the 1.1 trunk.
Attachment #91103 - Flags: approval+
(Reporter)

Comment 11

17 years ago
First patch is checked in
(Reporter)

Comment 12

17 years ago
Posted patch Work in progress (obsolete) — Splinter Review
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?
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

17 years ago
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.
(Reporter)

Comment 15

17 years ago
Posted patch Work in progress (obsolete) — Splinter Review
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.
Attachment #91966 - Attachment is obsolete: true
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.

Updated

17 years ago
Summary: Supress error page urls and session history → Suppress error page urls and session history

Comment 17

17 years ago
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

17 years ago
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

17 years ago
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.

Updated

17 years ago
Summary: Suppress error page urls and session history → Use original URL in history and URL bar when an error page is generated

Comment 20

17 years ago
*** Bug 160626 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 21

17 years ago
*** Bug 162266 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 22

17 years ago
*** Bug 160548 has been marked as a duplicate of this bug. ***
*** Bug 171292 has been marked as a duplicate of this bug. ***
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

17 years ago
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

17 years ago
> 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. :)

Updated

17 years ago
Keywords: mozilla1.3
Whiteboard: [Hixie-P0]
(Reporter)

Comment 27

16 years ago
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.
Attachment #92949 - Attachment is obsolete: true

Updated

16 years ago
Flags: blocking1.4a?

Updated

16 years ago
Flags: blocking1.4a? → blocking1.4a-

Updated

16 years ago
Flags: blocking1.4b?
Keywords: mozilla1.3nsbeta1

Updated

16 years ago
Flags: blocking1.4b? → blocking1.4b-

Comment 28

16 years ago
adt: nsbeta1-
Keywords: nsbeta1nsbeta1-

Comment 29

16 years ago
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?
*** Bug 210866 has been marked as a duplicate of this bug. ***
*** Bug 213120 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Flags: blocking1.6a?
*** Bug 222383 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Flags: blocking1.6b?
Flags: blocking1.6a?
Flags: blocking1.4.2?

Comment 33

16 years ago
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.
Flags: blocking1.6a?
How about a 1.7a target?
Not going to block 1.6 for this. Who can own this? Bryner, jst, danm?
Flags: blocking1.6b? → blocking1.6b+

Updated

16 years ago
Flags: blocking1.6b+ → blocking1.6b-

Comment 36

16 years ago
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

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

Comment 38

16 years ago
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

16 years ago
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

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

Updated

16 years ago
Flags: blocking1.7a?

Comment 41

15 years ago
think we will have this by 1.7 beta?
Flags: blocking1.7a? → blocking1.7a-

Updated

15 years ago
Flags: blocking1.4.2? → blocking1.4.2-

Comment 42

15 years ago
*** Bug 224658 has been marked as a duplicate of this bug. ***
*** Bug 237360 has been marked as a duplicate of this bug. ***

Comment 44

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

Updated

15 years ago
Flags: blocking1.7?

Updated

15 years ago
Flags: blocking1.7?
Flags: blocking1.7-
Flags: blocking1.6b-
Flags: blocking1.4b-
Flags: blocking1.4a-
Flags: blocking1.4.2-

Updated

15 years ago
Flags: blocking1.8a2?

Updated

15 years ago
Flags: blocking1.8a2? → blocking1.8a2-

Comment 45

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

Comment 46

15 years ago
Any chance this can be fixed for FF1.0RC1?  It's a real pain.
Flags: blocking-aviary1.0RC1?

Comment 47

15 years ago
danm, want to take on this bug?
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-

Updated

15 years ago
Blocks: 216466

Comment 48

15 years ago
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

15 years ago
*** Bug 266659 has been marked as a duplicate of this bug. ***
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.
Posted patch alternative patch (obsolete) — Splinter Review
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
Assignee: adamlock → cbiesinger
Status: NEW → ASSIGNED

Comment 52

15 years ago
Comment on attachment 164200 [details] [diff] [review]
alternative patch

shouldn't this set LOAD_BACKGROUND on the error page channel?
(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

15 years ago
> 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.
Posted patch alternative patch v2 (obsolete) — Splinter Review
this also fixes problems with session history. all of reload, back and forward
now seem to work correctly.
Attachment #164200 - Attachment is obsolete: true
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.
Attachment #164233 - Flags: review?(bzbarsky)
oh, and this _does_ use LOAD_BACKGROUND now, with some fixes to the html.
Target Milestone: --- → mozilla1.8alpha6

Comment 58

15 years ago
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

Updated

15 years ago
Flags: blocking-aviary1.0?
Max: that is a different bug. this one is about error pages, which are not
enabled unless you set a hidden pref.

Comment 60

15 years ago
hrm, ok. perhaps the summary should be adjusted - it doesn't seem to match the
'description'.
not gonna happen for firefox 1.0
Flags: blocking1.8a2-
Flags: blocking1.7a-
Flags: blocking1.7-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0-
*** Bug 268112 has been marked as a duplicate of this bug. ***
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...
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

15 years ago
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

15 years ago
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.)
(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
*** Bug 273159 has been marked as a duplicate of this bug. ***
(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.
Attachment #164233 - Attachment is obsolete: true
Attachment #164233 - Flags: review?(bzbarsky)
Attachment #168419 - Flags: review?(bzbarsky)
>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
*** Bug 250955 has been marked as a duplicate of this bug. ***
*** Bug 274917 has been marked as a duplicate of this bug. ***
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".... :(
Attachment #168419 - Flags: review?(bzbarsky) → review+

Comment 75

14 years ago
This missed 1.8a6 will it land for 1.8b?
Flags: blocking1.8b?
- 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...
Attachment #168419 - Attachment is obsolete: true
Attachment #172771 - Flags: review?(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
Attachment #172771 - Flags: review?(bzbarsky) → review+
ok, made that change
Attachment #172838 - Flags: superreview?(darin)
Summary: Use original URL in history and URL bar when an error page is generated → Use original URL in history and URL bar when an error page is generated (show failed url)
*** Bug 280455 has been marked as a duplicate of this bug. ***

Comment 80

14 years ago
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?
Attachment #172838 - Flags: superreview?(darin) → superreview+
Comment on attachment 172838 [details] [diff] [review]
patch v5 (checked in, except nsIDOMLocation)

OK. I checked this patch in, except the nsIDOMLocation.idl part
Attachment #172838 - Attachment description: patch v5 → patch v5 (checked in, except nsIDOMLocation)
this patch changes nsIDOMLocation.idl as requested by bz in comment 77; also
note comment 80
Attachment #172943 - Flags: superreview?(jst)
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 on attachment 172943 [details] [diff] [review]
nsIDOMLocation patch

r+sr=jst
Attachment #172943 - Flags: superreview?(jst)
Attachment #172943 - Flags: superreview+
Attachment #172943 - Flags: review+

Comment 85

14 years ago
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.
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

14 years ago
(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

14 years ago
It's on my list to look at what this does to the accessibility code.
(In reply to comment #87)
> Is that bug 215753?

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

Comment 90

14 years ago
*** Bug 281598 has been marked as a duplicate of this bug. ***
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).
Flags: blocking1.8b? → blocking1.8b-
filed bug 285055 on comment 83. marking this one fixed.
No longer blocks: 285055
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 93

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

Comment 94

14 years ago
*** Bug 226401 has been marked as a duplicate of this bug. ***
*** Bug 288641 has been marked as a duplicate of this bug. ***
*** Bug 288643 has been marked as a duplicate of this bug. ***

Comment 97

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

Updated

14 years ago
Blocks: majorbugs

Updated

14 years ago
No longer blocks: majorbugs
*** Bug 307503 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.