Closed Bug 298657 Opened 19 years ago Closed 19 years ago

Set browser.xul.error_pages.enabled to true for suite?

Categories

(SeaMonkey :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: svl-bmo, Assigned: csthomas)

References

Details

Attachments

(1 file)

Firefox has just set browser.xul.error_pages.enabled to true in bug 216466.
Should we do the same?

The biggest issue would probably be bug 290219.
(In reply to comment #0)
> Firefox has just set browser.xul.error_pages.enabled to true in bug 216466.
> Should we do the same?

We've been discussing the matter a few times internally on IRC, and we always
thought quite positive, given the main issues are resolved. So I guess if
Firefox people think it's goood to go, we should as well. I don't think we got
more users risky of filing a load of bug reports than them ;-)

> The biggest issue would probably be bug 290219.

I guess that's an issue for Firefox as well, so IMO if they're happy for now to
enable error page despite of it, we shouldn't worry as well.
We shouldn't be exposing a checkbox in the UI that breaks thing (and disabling
JS breaks a lot).  So bug 290219 should block release or we need to workaround
it (disabling JS disables XUL error pages).  I noticed that bug 216466 also
lists security bug 292624 as a dependency.
ajschult, so whay does Firefox enable error pages by default then?
becaue they're either unaware of the issue (no mention of the bug in bug
216466), think it can be fixed in time or don't care.

We know about the issue, I see nothing to suggest the fix would be simple (also
nothing to suggest it would be hard) and I care.
Meanwhile, bug 290219 has received blocking 1.8b4+ and bsmedberg is saying that
he'll probably fix it along with the security bug, so that looks hopeful.
excellent
Flags: blocking-seamonkey1.0a?
yeah, I think we want this for alpha if we can fix the javascript disabling issue.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a+
I think we should enable this on trunk and for alpha in any case, we can always
turn it off again on branch for beta and/or final when we still have too big
open issues to ship a polished product with it.
I think though that we want wide testing for it to catch all those issues.
Assignee: general → cst
Status: NEW → ASSIGNED
Attachment #188145 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #188145 - Flags: review?(neil.parkwaycc.co.uk)
I even got reports now that apparently error pages seem to work with JS disabled
even if bug 290219 is not marked fixed yet...

This would be one reason more to turn this on for Alpha and get testing on those
things.
Attachment #188145 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #188145 - Flags: superreview+
Attachment #188145 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #188145 - Flags: review+
Attachment #188145 - Flags: approval1.8b3?
Depends on: 300022
Attachment #188145 - Flags: approval1.8b3? → approval1.8b3+
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
QA Contact: general → stdonner
Resolution: --- → FIXED
Verified FIXED with build 2005-07-09-06 on Windows XP, this is most definitely in.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: