Closed
Bug 601201
Opened 14 years ago
Closed 14 years ago
show Error Console in menu for beta 7
Categories
(Firefox :: Menus, defect)
Firefox
Menus
Tracking
()
VERIFIED
FIXED
Firefox 4.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: beltzner, Assigned: pcwalton)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
(deleted),
patch
|
beltzner
:
review+
rcampbell
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
Dolske
:
review+
|
Details | Diff | Splinter Review |
In bug 587734 comment 37 Shaver points out that since the Web Console doesn't collect errors when it's not shown, it might end up being a pain for website developers who are going to use Beta 7 to evaluate their compatibility with Firefox 4, etc.
We might better flip the default value of devtools.errorconsole.enabled for beta 7, then flip it back again right after.
Reporter | ||
Comment 1•14 years ago
|
||
Adding Johnath, Kevin and Rob who can make the call about whether or not this is WONTFIX or something we want to do.
blocking2.0: --- → beta7+
Comment 2•14 years ago
|
||
We will never surface all chrome and xpconnect
errors in the web console anyway. It would not be a crime to have a "Browser
Console" as well as a "Web Console" - unless we figure out the slick UX and UI
for this problem. This has been a conundrum for me since day one.
Comment 3•14 years ago
|
||
ddahl: the decision to remove the Error Console in the first place is that the audience for chrome errors is generally quite small.
I think it's perfectly reasonable to leave the Error Console turned on for beta 7. As beltzner points out, it's just flipping a bit.
Assignee | ||
Comment 4•14 years ago
|
||
Proposed patch attached.
Comment 5•14 years ago
|
||
(In reply to comment #3)
> ddahl: the decision to remove the Error Console in the first place is that the
> audience for chrome errors is generally quite small.
>
> I think it's perfectly reasonable to leave the Error Console turned on for beta
> 7. As beltzner points out, it's just flipping a bit.
Indeed. No problem. The real issue is creating an elegant, discoverable UX/UI for developers who need global/xpconnect/chrome error logging.
Comment 6•14 years ago
|
||
AIUI this particular bug has nothing to do with the xpconnect/chrome errors, it has to do with the fact that _web_ errors aren't cached. This means that if I didn't yet open the Web Console (or if I've closed it since I opened it) I won't get the previous collected errors from the website I'm on. This, IMHO, is a _very_ big problem with the current console...
Comment 7•14 years ago
|
||
(In reply to comment #6)
> This, IMHO, is a _very_ big problem with the current console...
indeed, this goes without saying. see bug 601260. My point was about the reasons we hid the JS Error console, which were poorly thought out.
Comment 8•14 years ago
|
||
Comment on attachment 480281 [details] [diff] [review]
Proposed patch.
this patch should do the job.
Attachment #480281 -
Flags: review+
Comment 9•14 years ago
|
||
I think for b7 (and possibly future) it makes sense to re-enable the Error Console given the current limitations in the Web Console. Note that if we do this, and decide to leave the Error Console in and enabled for future versions, it will continue to have the same title and wording as it does in previous versions. I.e., Error Console (not Browser console or whatever else we might want to rename it as).
Reporter | ||
Updated•14 years ago
|
Attachment #480281 -
Flags: review?(beltzner) → review+
Reporter | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [can land]
Comment 10•14 years ago
|
||
This should be Platform "All", right?
Assignee | ||
Updated•14 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Assignee | ||
Comment 11•14 years ago
|
||
(In reply to comment #10)
> This should be Platform "All", right?
Yes.
Comment 12•14 years ago
|
||
Blocks: 593538
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
No longer depends on: 593538
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [can land]
Target Milestone: --- → Firefox 4.0b7
Comment 13•14 years ago
|
||
Changing the default pref is going to remove it from user prefs, which will annoy people who've already flipped it when we change it back later. I think we should just short-circuit the pref flip instead.
Comment 14•14 years ago
|
||
That is, I propose we take this followup.
Updated•14 years ago
|
Attachment #480934 -
Flags: review?(dao)
Updated•14 years ago
|
Attachment #480934 -
Flags: review?(dao) → review+
Comment 15•14 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b31a8581f14b
Filed bug 602006 to undo this.
Comment 16•14 years ago
|
||
Quoting Mike, #1...
"since the Web Console doesn't
collect errors when it's not shown, it might end up being a pain for website
developers who are going to use Beta 7 to evaluate their compatibility with
Firefox 4, etc."
Here's another one of them ;-)
Yes, keep that thing in guys. Besides, don't forget that the EC can operate independently in a separate window (a MUST) for me, while it will always weave itself in into the current page (which can emerge into a pretty cumbersome scrolling-up-down job)
Comment 17•14 years ago
|
||
it = the Web Console
Comment 18•14 years ago
|
||
Verified with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b7pre) Gecko/20101006 Firefox/4.0b7pre
Status: RESOLVED → VERIFIED
Comment 19•14 years ago
|
||
And re-added the manual test for now:
https://litmus.mozilla.org/show_test.cgi?id=10032
Flags: in-litmus+
You need to log in
before you can comment on or make changes to this bug.
Description
•