Closed Bug 256213 Opened 20 years ago Closed 20 years ago

hide JS console

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: asa, Assigned: steffen.wilberg)

Details

(Whiteboard: [have patch])

Attachments

(1 file, 2 obsolete files)

hide the console
6.34 KB, patch
Details | Diff | Splinter Review 
View Source and JavaScript console are both developer tools and should be moved
out of the primary end user UI. The developer pack is the right place for those
tools. 

This bug is for getting those menu items moved to be conditional on the
developer pack being installed from the custom install panel in the Firefox
installer.
Flags: blocking-aviary1.0PR+
Depends on: 213950
bug 213950 was the old discussion about just the JS console.
No longer depends on: 213950
I don't agree that View Source is a 'developer tool'. While it is used by
developers, that doesn't mean that non-devs don't use it. One example is the
everyday blogger user, who may want to refer to the source of someone else's
blog or website to see how some aspect was implemented. This doesn't make them
developers, persay, and these people most likely will not select 'developer
tools' when installing. I think it will come across to most users as a loss,
feature-wise, when compared to other browsers, namely IE.
I don't agree that View Source is a 'developer tool'. While it is used by
developers, that doesn't mean that non-devs don't use it. One example is the
everyday blogger user, who may want to refer to the source of someone else's
blog or website to see how some aspect was implemented. This doesn't make them
developers, persay, and these people most likely will not select 'developer
tools' when installing. I think it will come across to most users as a loss,
feature-wise, when compared to other browsers, namely IE.
The everyday blogger user can install the developer tools (they'll love dom
inspector too) or they can use view-souce:myblog.com and see the source just
fine (they can also use javascript: to get at the JS console). Bloggers are
about 1/10000000000000 of the people we're targeting for migration to this
browser. They're typically more advanced users and can find the extension or
custom install they need. 
The Javascript console is an incredibly important tool for debugging problems
users have with websites. Question 1 is "check the javascript console"

This is a bad move.
mike, instead of telling the user to check the javascript console (I'm trying to
remember the last time the phone company or cable company said they couldn't fix
my service problem unless I checked a javascript console) you can tell them to
type "javascript:" in the addressbar.
(In reply to comment #6)
> mike, instead of telling the user to check the javascript console (I'm trying to
> remember the last time the phone company or cable company said they couldn't fix
> my service problem unless I checked a javascript console) you can tell them to
> type "javascript:" in the addressbar.

Actually now that I have gotten over my shock and re-read your blog post, this
move makes perfect sense to me. While I do think that all users should have
access to the functionality (which they will under this plan), the clutter in
context menus needs to go. I was under the impression that the actual
functionality was being moved into the Dev Tools. Sorry about the confusion.
I kind of have to agree with mkaply and sunil.

They are often used in tech support.  Removing this makes it harder for an
already hesitant webmaster to consider supporting mozilla

View Source in particular is essential, if not just a parallel feature with IE,
and every other browser I can think of.

If 1 has to go, just remove JS console from the menu.  But I'd be hestant.  
If all you wanted to do was remove it from the context menu, couldn't you just
change the default userChrome.css?
http://kb.mozillazine.org/index.phtml?title=Firefox_:_Tips_:_Customize_context_menu
I frequently tell people complaining about overlapping text or other readability
or access problems that they can find what they need using view source. I'm not
going to tell them or expect them to remember view-souce:myblog.com. I'm going
to tell them to use Mozilla.
I haven't tested this *at all*.  I do not have a computer now on which I can
feasibly build Firefox.  Until this is tested by someone, I will not ask for a
review because it would likely be a waste of time.  The good news is that if it
doesn't work, it's probably 90% done.

Please apply this at the top of the tree and then follow the directions for the
next attachment (because new files are created and I don't have commit access
-- stupid cvs, requiring commit access to diff new files is idiotic).
Attached file Contains new files (obsolete) — 
Open this zip file.  Inside are two folders: viewsource and console.  Copy the
contents of viewsource into mozilla/toolkit/components/viewsource/content, and
copy the contents of console into mozilla/toolkit/components/console/content. 
With the previous patch applied, you should theoretically be good to go.  Post
back with results from the patch so I know if it completely screws anything up.


Note also that this patch and the patch for bug 254175 (fully localize
installer) will conflict horribly.
I think this is a bad decision. I see the point though : (a) reduce the code
size again and again (b) make the difference between average users and advanced.
But even beginners using a browser may have, only once in a lifetime, the *real*
need for a JS console or a source views when a sysadmin comes on their machine
to debug something. The guy is not going to load an XPI in Firefox if he has to
do that on every single machine he works on for the day.
Furthermore, you know how works the Web : people who write their first home page
start copying some markup chunks from the Source View; if you break that, the
media are going to fall on us, and they will be right to do it.

I urge you to reconsider this decision, I do believe it's a bad one, and a very
bad one.
(In reply to comment #0)
> View Source and JavaScript console are both developer tools and should be moved
> out of the primary end user UI. The developer pack is the right place for those
> tools. 

The JavaScript console can be considered a developer tool but View Source can't
be. I dont agree with the decision of removing the view source menuitem.
(In reply to comment #10)
> I frequently tell people 

What "people"? Regular end users? 

> complaining about overlapping text or other readability or access 
> problems that they can find what they need using view source.

And what is it that these users "need"? How will showing them how the website is
broken help them browser the website better?

> I'm not going to tell them or expect them to remember view-souce:myblog.com.
> I'm going to tell them to use Mozilla.

You can tell these people (who are they, again?) to go to the View menu, mouse
down to the Page Source menuitem and click it, but you can't tell them to press
ctrl+u on their keyboards? Who are these keyboardless users that need to be
viewing source all the time? 
(In reply to comment #15)

I think we're pretty much in agreement about why this bug exists, but with that
last comment, it seems like you are taking a very extremist viewpoint in the
sense that there should be absolutely no UI entrypoint into the view source dialog. 

I can see your reasoning behind removing it from the context menu (to remove
clutter), but why also remove it from the View menu? I don't see how it hurts to
leave at least one entrypoint, there, if no where else. 

By leaving functionality in and only letting people that know the 'tips and
tricks' access to them, it only alienates the 'developers' (and other users who
don't consider themselves power users but very well may be in your viewpoint)
and are used to the View Source functionality in IE, Mozilla/Netscape, and even
previous versions of Firefox.

And using your logic, the Character Encoding menu and Page Info should also be
stripped out because they're not used by the 'average' user. IMO, it's good for
Firefox to be lean, but not so lean that you end up with an empty shell.

This comment doesn't apply at all to the JS Console, which, unlike View Source,
is completely a developer tool as far as I am concerned. For that, I don't mind
if the functionality itself is moved out of the default installation. Page
source should remain no matter what, even if it doesn't have a UI entrypoint in
the end.

Just my $.02, FWIW.
The plan it just to remove the menu item from the main menu and context menu,
not the function, right? So there's no code size or download size change - it's
just a UI thing?

This means you will no longer have any way to view the source of frames without
opening them on their own, which doesn't always work (To solve this, you could
leave "View Frame Source" behind - it's on a sub-menu after all.)

Are you planning to also remove "View Selection Source"?

Gerv
updating summary to cover just the JS console. we can fight about view source
elsewhere.
Summary: move JS console and view source into developer pack → move JS console developer pack
If a feature is available, accessibility would make this feature accessible by
both keyboard or mouse

Another argument against this decision :

A lot of linux packages (some rpm, maybe deb) don't include DOM Inspector, so i
supose it will do the same with the view-source feature. So a lot of 'advanced'
people who use 'view-source' will be confuse by not seeing the option in the
'view' menu.
(In reply to comment #18)
> updating summary to cover just the JS console. we can fight about view source
> elsewhere.

Related seamonkey bug: http://bugzilla.mozilla.org/show_bug.cgi?id=145021
(In reply to comment #18)
> updating summary to cover just the JS console. we can fight about view source
> elsewhere.

so it's now a duplicate of bug 213950.
Did you already know that we have BiDi UI in the Edit, View and context menus?
No? Go to about:config, set bidi.browser.ui to true and restart Firefox.

We should do a similar thing here. Hide the JS Console menuitem unless either
DOM Inspector is displayed, which means the user has installed developer tools,
or he has set an override pref.

The advantage is that the user can be advised to set that pref, restart Firefox,
and look into the console without installing an extension. And we don't have to
create and maintain such an extension.

Taking.
Assignee: firefox → steffen.wilberg
Summary: move JS console developer pack → hide JS console
Perhaps a better solution is when you create a profile, it asks if you want to
use 'power user mode' or 'simple mode'.

Based on the setting, the browser would then adjust the UI appropriately. 
Making the menu's simpler for casual users, and more robust (and useful) for
regular users.

A library for example may go with 'simple mode', but a computer lab would want
'power user mode'.
Attached patch hide the console — — Splinter Review 
The JS Console menu item is hidden by default, and only shown if either DOM
Inspector is there as well, or the pref "browser.showDeveloperTools" is set to
true.

I can easily do the same for View (Page/Frame/Selection/MathML) Source.
Attachment #156565 - Attachment is obsolete: true
Attachment #156566 - Attachment is obsolete: true
Comment on attachment 156587 [details] [diff] [review]
hide the console

Blake, this is for you :)

To test this, close Firefox and remove the line
  <RDF:li>chrome://inspector/content/tasksOverlay.xul</RDF:li>
from <appdir>/chrome/overlayinfo/browser/content/overlays.rdf.

Restart Firefox. Both DOM Inspector and JS Console are gone.
Now go to about:config and add a boolpref "browser.showDeveloperTools", set to
true. Open a new window, and the JS Console is in the menu again.
Attachment #156587 - Flags: review?(firefox)
Note that <appdir>/chrome/overlayinfo/ is created upon the first startup of
Firefox or when <appdir>/chrome/chrome.rdf is missing. So overlayinfo isn't
there yet on a fresh install unless you start Firefox for the first time.
To get DOMi back, put that line back in, or delete chrome.rdf, so that
overlayinfo is recreated.

Robert, I guess the profile manager could set the pref. But the profile manager
is to be removed as well sooner or later, see bug 214675  :)
Whiteboard: [have patch]
(In reply to comment #21)
> so it's now a duplicate of bug 213950.

No, that is about actually pulling all the code into a separate extension pack.
This is simply about UI (a hack for 1.0, to be done right wih 213950 for 1.5).


(In reply to comment #15)
> (In reply to comment #10)
> > I frequently tell people 
 
> What "people"? Regular end users? 

Yes
 
> > complaining about overlapping text or other readability or access 
> > problems that they can find what they need using view source.

> And what is it that these users "need"? How will showing them how the website is
> broken help them browser the website better?

When you need something from a website that you can't get from the normal
display or some alternate page you can usually capture that information from the
source. People don't have time to wait for a TE bug fix or an email complaining
to the webmaster that the page is broken.
 
> > I'm not going to tell them or expect them to remember view-souce:myblog.com.
> > I'm going to tell them to use Mozilla.
 
> You can tell these people (who are they, again?) to go to the View menu, mouse
> down to the Page Source menuitem and click it, but you can't tell them to press
> ctrl+u on their keyboards? Who are these keyboardless users that need to be
> viewing source all the time? 

I'm not sure I know any keyboardless users, but most if not all I know are used
to doing all things other than input entry with a mouse only. Who's going to
remember what Ctrl-U does if the reminder doesn't remain in the view menu?

So, where is view source "fight" supposed to be now?
IE has an option to disable script debugging. It is disabled by default. This is
basically what we are doing here, right? (except enabling via hidden pref or dev
tools and not via an option)

The thing is - even when disabled, IE still has a notification that something is
wrong (yellow triangle in bottom-left statusbar). Details of the error aren't
immediately forthcoming, but that doesn't matter - the user is aware that there
is something wrong with the page and that the *browser knows it*. Without this,
users are going to assume that the browser is incapable, and go back to IE.

We should have such an icon anyway IMHO, but I feel its even more important if
easy access to the JS console is being taken away for more confident users to
access (note that I did NOT say power users).
(In reply to comment #29)
> We should have such an icon anyway IMHO, but I feel its even more important if
> easy access to the JS console is being taken away for more confident users to
> access (note that I did NOT say power users).

Not a bad idea.  Get rid of it in the menu, but put an icon.  Double click the
icon for the console.  Perhaps mouseover to get the last error returned.  Would
be easier for debugging at times as well.
Now if I run into a site that doesn't work, and I complain to the webmaster, I
can't even tell the webmaster I get an JavaScript error?!
Oh I can use "javascript:" int the URL-bar? Where should I know that from? I'm
not really a web-developer, just an experienced user who knows what JavaScript
generally is and that it can have errors (A user just like most Firefox users I
guess).

(Actually *I am* a developer, and even I had forgotten about the "javascript:"
prompt, and has never used (or known) the shortcut for "View source").

Are there any bugs against this bug I can put my vote on?
Asa wrote:
"This is simply about UI (a hack for 1.0, to be done right wih 213950 for 1.5)."

In that case, the first (now obsolete) patch, was a better solution, wasn't it?
Otherwise we're adding a pref which will control something in 1.0, and then in
1.5 the pref will be obsolete in favour of an extension.  If it's going to be an
extension ultimately, then it would be better to have it as an extension (albeit
a hack) now, wouldn't it?
I think the nest way to deal with it is to include a context menu editor by
default. Leave the javascript console and view source coding intact; just hide
them by default if you find it necessary, and then a user can add them and other
entries by editing the context menu options. So a crude mockup would be
something like this:

Context Menu Display Options
----------------------------
Tools
-----
[X] Web Search
[X] Downloads
[X] Extensions
[x] Themes
[ ] Javascript Console
[X] Page Info
[X} Options


...and you could even include perhaps a password-accessible-only feature to get
to this context menu editor, so you could essentially make a kiosk browser by
removing all items deemed unnecessary.
not gonna happen.
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking-aviary1.0PR+
Resolution: --- → WONTFIX
Attachment #156587 - Flags: review?(firefox)
(In reply to comment #34)
> not gonna happen.

Open Source with a strong community does work.
Instead of just "Default" and "Developer", what about:
Minimal:
- View (selection) source
Normal:
- View (selection) source
= RSS/Atom (Live bookmark)
- JavaScript console
Full:
- View (selection) source
= RSS/Atom (Live bookmark)
- JavaScript console
- DOM console
- Venkman
Custom:
- Choose anything you want
thanks god for the fixed wonfix status ...

but

I would like somebody to explain me why one of a leader in a project heading to
1.0 final is wasting his time and the time of others to explore a path
everybody's against at the first place (don't serve me that dictatorship story,
we all know that) while there are tons of bugs to clean in that product, that
the release date is always postponed, etc. etc.

again, thanks for the fixed wontfix status, and the core leaders should meditate
on this
Status: RESOLVED → VERIFIED
QA Contact: bugzilla → menus
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: