Last Comment Bug 213950 - Separate js console
: Separate js console
Status: RESOLVED WONTFIX
:
Product: Toolkit Graveyard
Classification: Graveyard
Component: Error Console (show other bugs)
: Trunk
: All All
: -- normal with 12 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 213949 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-25 19:29 PDT by Blake Ross
Modified: 2016-06-29 11:02 PDT (History)
31 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Blake Ross 2003-07-25 19:29:40 PDT
It will be in a web developer pack in our installer.
Comment 1 Bill Mason 2003-07-25 20:41:02 PDT
*** Bug 213949 has been marked as a duplicate of this bug. ***
Comment 2 Brant Gurganus 2003-08-20 14:47:56 PDT
Users still need a way to see that an error is with the web site, not the
browser configuration.  Otherwise, we will end up with a lot of invalid bugs or
new sites that webmasters tested in Firebird and got no errors.
Comment 3 Jesse Ruderman 2003-09-07 15:06:21 PDT
I agree with Brant that there should be a way to see web page errors without
installing the web developer pack.  The JavaScript console isn't the best way to
do that, though.  I prefer IE's status bar icon and message.
Comment 4 Florian Sievert 2003-09-27 12:08:34 PDT
Also think it is important for End Users to see, if there happens some errors in
the page. However we still fighting against some sites "optimized" for the
Internet Explorer that occures some errors in java script in Firebird. A
feedback about the error that prefend the correct using of the website would
stop irrtitating the user. The current way is still better solved than the way
the IE do. But maybe it would be a nice additional work to show a small icon at
the bottom left to show that the site caused an error, similar to the IE. As a
web developer I also would like such a feature.
Comment 5 alanjstr 2003-10-06 20:28:30 PDT
Statusbar notification extension.  But it needs a little work.
http://extensionroom.mozdev.org/#jsstatus
Comment 6 Per Ångström 2003-10-11 10:29:26 PDT
Sorry for the bugspam, but I need to express my agreement with the other
dissenting comments. 

So if a user has a problem with a page, we'll have to ask them to install the
web developer pack, just to see the JavaScript console? I can't see the use in
removing a debugging feature from a product that is still under development.
Comment 7 Robert Accettura [:raccettura] 2003-10-29 18:12:05 PST
I agree with comment 3.  


There should be a cleaner, more user friendly method for end users. 

Web Developers should get the more detailed flexible js console... to the end
user it's confusing.
Comment 8 Ben Goodger (use ben at mozilla dot org for email) 2003-12-15 14:22:40 PST
-> 0.9
Comment 9 Hiro 2004-03-12 13:45:37 PST
Does this problem argue about the installer package of windows?
Is it the meaning that Java Script Console is not chosen in standard installation?
Or is it the meaning to deleting from a package completely?

Now, there is no installer package of a Mac-OS-X version.
(That is, there is no means to choose this function at the time of installation.)
When deleted completely, people to use these functions are troubled.
Comment 10 kaldari 2004-04-11 18:25:01 PDT
I too would like a clarification on whether or not the JavaScript console will
be available for the Mac version (since there is no installer).
Comment 11 Adam Katz 2004-04-28 23:59:43 PDT
how much space does elimination of the js console give?
are there other reason(s) for removing it?

if a main reason for this removal is simplicity of menus/ui, we could remove it
from the menus and make it remain accessible by going to the url "javascript:"

i'd hate to have to use "javascript:alert(...)" to debug on machines i do not
administer and agree with comment 3; there must be a way to report js errors.
Comment 12 Don't need your account 2004-05-04 13:59:56 PDT
This tool is great! Do You prefer MSIE JS behaviour?
Comment 13 David Mårtensson 2004-05-17 06:07:18 PDT
I belive a solution like comment #11 is good but with a slight change.

I whould prefere to use javascript:console to open the console.

Before switching to IE as the default browser on our company I remember getting
a lot of questions from bevildered users that got the console poping up in their
face.

Apparently many IE web developers uses "javascript:" as a no action link url
when they whant to use onclick event instead, i know this is bad practice but I
do not fancy getting the same mass of user support question again if we where to
switch to firefox.
Comment 14 Steffen Wilberg 2004-07-06 12:15:27 PDT
-> js console.
Comment 15 Greg Wogan-Browne 2004-08-19 18:50:19 PDT
I think syntactically about:javascript would be better than javascript:console.
It's more in line with current usage. javascript: should be for the execution of
javascript code only.
Comment 16 Phil Ringnalda (:philor) 2007-02-11 00:35:32 PST
Unlikely, at this point. Certainly not blocking bug 171082, since it was about the custom install option, not about an extension or a stub installer that would take it clear out of the download.
Comment 17 Joe Walker [:jwalker] (needinfo me or ping on irc) 2013-04-04 02:41:49 PDT
Marking resolved fixed as we now have a built-in web console and scratchpad which amply cover the needs of this bug.
Comment 18 Colby Russell :crussell (no longer Mozilla-ing) 2013-04-30 14:56:09 PDT
Isn't the browser console Firefox-only?  This bug is for Toolkit.
Comment 19 Philip Chee 2013-04-30 20:59:20 PDT
> Isn't the browser console Firefox-only?  This bug is for Toolkit.
Oh good point. I'll reopen, or perhaps repurpose this bug to move the web console and scratchpad to toolkit.
Comment 20 Brian Grinstead [:bgrins] 2016-06-27 07:47:49 PDT
The Error Console has been removed in favor of the Browser Console (see Bug 1278368), and the component is going to be removed.  If this bug is also relevant in the Browser Console, please reopen and move this into Firefox -> Developer Tools: Console.
Comment 21 Zack Weinberg (:zwol) 2016-06-27 09:43:30 PDT
I am mass-reopening and re-componenting every single one of the Toolkit:Error Console bugs that appear to have been closed without anyone even *glancing* at whether they were relevant to the Browser Console.

If you want to close a whole bunch of old bugs -- FOR ANY REASON -- it is YOUR RESPONSIBILITY to check EVERY SINGLE ONE OF THEM and make sure they are no longer valid.  Do not push that work onto the bug reporters.

(It's okay to close bugs that haven't been touched in years when they don't have enough information for you to figure out whether the problem is still relevant to the current software - the reporter probably isn't coming back to clarify.  But that is the ONLY situation where it is okay.)

(I'm going to have to do this in two steps because of the way the "change several bugs at once" form works.  Apologies for the extra bugspam.)
Comment 22 Brian Grinstead [:bgrins] 2016-06-27 13:29:08 PDT
The Browser Console has been ported to toolkit

Note You need to log in before you can comment on or make changes to this bug.