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)
SeaMonkey
General
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: svl-bmo, Assigned: csthomas)
References
Details
Attachments
(1 file)
1.14 KB,
patch
|
neil
:
review+
neil
:
superreview+
roc
:
approval1.8b3+
|
Details | Diff | Splinter Review |
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.
Comment 1•19 years ago
|
||
(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.
Comment 2•19 years ago
|
||
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.
Comment 3•19 years ago
|
||
ajschult, so whay does Firefox enable error pages by default then?
Comment 4•19 years ago
|
||
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.
Comment 7•19 years ago
|
||
yeah, I think we want this for alpha if we can fix the javascript disabling issue.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a+
Comment 8•19 years ago
|
||
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 | ||
Comment 9•19 years ago
|
||
Assignee: general → cst
Status: NEW → ASSIGNED
Attachment #188145 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #188145 -
Flags: review?(neil.parkwaycc.co.uk)
Comment 10•19 years ago
|
||
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.
Updated•19 years ago
|
Attachment #188145 -
Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #188145 -
Flags: superreview+
Attachment #188145 -
Flags: review?(neil.parkwaycc.co.uk)
Attachment #188145 -
Flags: review+
Updated•19 years ago
|
Attachment #188145 -
Flags: approval1.8b3?
Attachment #188145 -
Flags: approval1.8b3? → approval1.8b3+
Assignee | ||
Updated•19 years ago
|
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.
Description
•