JavaScript Console should be renamed to Error Console

VERIFIED FIXED in mozilla1.8.1beta1

Status

Toolkit Graveyard
Error Console
VERIFIED FIXED
13 years ago
11 months ago

People

(Reporter: Hixie (not reading bugmail), Assigned: u88484)

Tracking

({verified1.8.1})

1.8 Branch
mozilla1.8.1beta1
verified1.8.1
Dependency tree / graph
Bug Flags:
blocking-firefox2 +

Details

Attachments

(1 attachment, 7 obsolete attachments)

(Reporter)

Description

13 years ago
The JS Console now does much more than just JS. We should rename it to something
like the Web Console or Error Console.
(Reporter)

Updated

13 years ago
No longer blocks: 6211

Updated

13 years ago
OS: Linux → All
Hardware: PC → All

Comment 1

13 years ago
Erm, shouldn't we do this for Seamonkey as well?
Assignee: bugs → nobody
Flags: blocking-aviary2?

Comment 2

12 years ago
I agree... here are some alternative ideas:

Message Console
Developer Console
Scripting Console
Script Console
Debug Console
Firefox Console
Error Console
*** Bug 316149 has been marked as a duplicate of this bug. ***

Comment 4

12 years ago
i think Debug-Console is the best name...

Pls split the errors/warnings/hints into languages (html/js/css) and error-types (unknown tags/syntax error)

is it possible to define own texteditor (in my case scite) for displaying sourcecode? I know the main-problem is to set the line-number where the error is...but there can be a command-line with variables for displaying in another editor like this:

...\scite.exe %(filename) -goto:%(linenumber)

Comment 5

12 years ago
"Debug Console" could be confused with the Javascript Debugger. 
Personally I like "Scripting Console", as the word scripting can refer to javascript, css, html, or any other kind of web script collectively.

Comment 6

12 years ago
I don't like 'scripting console' because it is geek-speak, and people don't normally talk of scripting CSS.
I agree 'debug console' is confusing.

Error console gets my vote.

Comment 7

12 years ago
Whatever it is called it should not have mixed JS and CSS messages. At this time firefox has no more JS Console. This thing that took its name and place is almost useless for any serious work. Just reloading Google page fills it up with so called "errors". There should be some mechanism in place that would let me see "JavaScript errors" in "JavaScript console" without all this CSS stuff. Well, uckily Opera still has JS console :)

Comment 8

12 years ago
Heh, I found extension called Console2. Very nice. It makes console even more usefull then before.

Comment 9

12 years ago
I vote for calling it "error console". "Javascript Console" is just misleading now that it covers CSS as well.

(In reply to comment #0)
> The JS Console now does much more than just JS. We should rename it to
> something
> like the Web Console or Error Console.
> 

Comment 10

12 years ago
"Developer Console" would get my vote, followed by "Debug Console". 

Comment 11

12 years ago
(In reply to comment #7)
> Whatever it is called it should not have mixed JS and CSS messages. At this
> time firefox has no more JS Console. This thing that took its name and place is
> almost useless for any serious work. Just reloading Google page fills it up
> with so called "errors". There should be some mechanism in place that would let
> me see "JavaScript errors" in "JavaScript console" without all this CSS stuff.

I second that.
I can't hear my javascript anymore because all the CSS is shouting at me.

I propose the CSS errors are lowered to 'warning', their rightful place, like bug 316200 also proposes. A CSS parse error does not require immediate attention -- if any at all. JS errors are less obvious from the code and the coder often requires help from the browser.

As for the name, I'd prefer 'Error Console', of if you're exact, 'Error Log'.

Comment 12

12 years ago
- I vote for anything that doesn't have the word "Console" in it. Suggest: "Page Debug Log" or similar.

- CSS properties that are valid CSS2/CSS3 but that Firefox has no support for yet (box-sizing, border-radius, background-size, etc.) should not be reported as errors or even warnings. If we really must report them, they should be at the "message" level.

- CSS properties that are valid in form but that custom properties for other browsers (filter, behavior, text-overflow, etc.) should be reported as "Warnings." If they are commonly found "in the wild", I would argue that they, too, should be moved to Messages. Cross-browser support demands some custom properties, the user agent should ignore what it doesn't understand as long as the syntax is valid, not throw errors.

- Suggest adding messages/warnings/errors relating to parsing of XHTML when Transitional or Strict DOCTYPE is in effect.

- There should be a way to both toggle-filter messages by source (JS, CSS, SVG, XHTML, etc.) and by severity (Error, Warning, Message). The "Clear" button should clear only the currently-filtered messages.

Updated

12 years ago
Flags: blocking-aviary2? → blocking-aviary2+
(Assignee)

Comment 13

12 years ago
Question: When creating a patch for this do we have to rename every instance of javascript console in the tree? like including extensions and inside jar files?

btw I propose 'Developer Console' and almost have a complete patch...just need to know if I need to add the above stuff or take out some other things. Easy to rename it if need be once I create the patch incase developer console is not wanted.
Keywords: uiwanted
(Assignee)

Updated

12 years ago
Assignee: nobody → supernova_00
(Assignee)

Comment 14

12 years ago
Created attachment 208757 [details] [diff] [review]
everything -mail/xpfe/calendar

Patch includes changes for everything except calendar, xpfe, and mail. Mail and xpfe coming up...caldendar I will get to in a few days.
(Assignee)

Updated

12 years ago
Attachment #208757 - Flags: ui-review?(beltzner)
(Assignee)

Comment 15

12 years ago
Created attachment 208759 [details] [diff] [review]
Mail patch
Attachment #208759 - Flags: ui-review?
(Assignee)

Updated

12 years ago
Attachment #208759 - Flags: ui-review? → ui-review?(beltzner)

Comment 16

12 years ago
What about just 'Console'?

Tools -> Console

Makes sense to me. Although Developer Console is probably the best of the rest. Error Console is technically incorrect, for the same reason as this bug was filed to start with.

Comment 17

12 years ago
I'd rather go with "Error Console" or "Message Console". While technically both of them are incorrect, IMHO they're the least confusing for non-developing users. Just imagine: you're having an extension or a website tested and you want all errors to be reported by any user...

> Developer Console
Implies that it's mainly for developers. Why would it then be installed everywhere? And would this make the reporting user to an assistant developer?

> Scripting Console
> Script Console
> Debug Console
These are all mainly geek-speak (as mentioned above). No need to confuse the users here. (Although I quite like Debug Console - since that's what it's used for)

> Firefox Console
Rather "Toolkit Console", but "Toolkit" won't mean anything to Joe User, either.

> Console
I'd vote for that one, if there weren't any other consoles to be mentioned with which that one could be confused (Java Console, System Console).

So unless the "Console" part shouldn't be dropped completely, I'd vote for the remaining two - so that you can ask your users to report the errors from the ... Error Console (or any messages from the Message Console) - which will make the most sense for them.

As for "Error Log", "Web Debug Log" et al., it sounds somewhat funny to evaluate some JavaScript code in a log (removing the JavaScript evaluation part would help - has that already been suggested?)...

Comment 18

12 years ago
(In reply to comment #17)
> > Firefox Console
> Rather "Toolkit Console", but "Toolkit" won't mean anything to Joe User,
> either.

Firefox Console is quite good I think, and a possibility (Thunderbird could have Thunderbird Console), it doesn't have to be Toolkit Console (which is indeed a rubbish name). However, there is no other menuitem (on Linux/Windows anyway, I know Mac is different) that has the brand name in it, with the exception of About... There is no 'Quit Firefox', or 'Firefox Help', which is why that may not be an option. I had thought that Console could be confusing (command console, Java Console etc.)

Comment 19

11 years ago
*** Bug 330845 has been marked as a duplicate of this bug. ***

Comment 20

11 years ago
Comment on attachment 208757 [details] [diff] [review]
everything -mail/xpfe/calendar

I think the safest way of doing this is not to change the menuitem id or the label and accesskey variable names.  Just change the strings in the .dtd files and be done with it.  This will break the fewest things in FF, and also any existing extensions that look for the menus by id will not have to be updated.
Comment on attachment 208759 [details] [diff] [review]
Mail patch

Dean, when we're changing strings, we change the entity names so that localizers will see the change and follow up.  The menuitem ids shouldn't change though, so extensions targeting bits are less likely to change.

Developer Console isn't really the right string, since that will be out of place for a default UI piece.
Attachment #208759 - Flags: ui-review?(beltzner) → review-

Updated

11 years ago
Attachment #208757 - Flags: ui-review?(beltzner)
Attachment #208757 - Flags: ui-review-
Attachment #208757 - Flags: review-
Beltzner and I went through the possibilities a while back and decided Error Console was the right choice.
Summary: JavaScript Console should be renamed → JavaScript Console should be renamed to Error Console
Target Milestone: --- → Firefox 2 alpha2

Comment 23

11 years ago
(In reply to comment #16)
> What about just 'Console'?

Agreed.
(Assignee)

Comment 24

11 years ago
(In reply to comment #22)
> Beltzner and I went through the possibilities a while back and decided Error
> Console was the right choice.
> 

Mike, with it being renamed to error console, I forsee dozens/hundreds of bugs/threads with users pasting every single error that shows in the console. They will think everysite with hundreds of css errors is a firefox bug and they will post away. Right now javascript console tends to keep the "noobs" away from that area since they don't technically understand what it is and how to use it. And developer console would do the same. 

Comment 25

11 years ago
All the more reason to have filtering in the core, if every last little CSS glitch is going to be spat out to normal users.

Comment 26

11 years ago
(In reply to comment #24)
> Mike, with it being renamed to error console, I forsee dozens/hundreds of
> bugs/threads with users pasting every single error that shows in the console.

First, CSS errors aren't errors anymore but only warnings (see bug 264162). And second, bug 312962 might even get as far as make the difference between CSS and JS errors (more) obvious (e.g. but not necessarily as Console² does). Third, we might even hide the CSS errors by default (see also below). And fourth, if we have to educate users about who is responsible for what, we'll lose only a little time (duping ain't that hard) and have (hopefully) more educated users as reward.

(In reply to comment #25)
> All the more reason to have filtering in the core, if every last little CSS
> glitch is going to be spat out to normal users.

Filtering should not go to the core but to the console itself (at least not more than we've got by mentioned bug 264162) - see bug 275265 for the work on this. I'd just vote for disabling to show CSS errors by default.

Comment 27

11 years ago
Any chance you could reconsider the name? IMO, Error console is almost as bad as  JavaSript console. If not "Developer Console" than simply "Console"?

I do see the point about dev console not being "out of
place for a default UI piece", but I think it makes sence to target it to developers. Developers are an important/the target audience for this feature and normal users will be confused to think the problem is with firefox - see comment 24.

I think you guys aren't giving users enough credit, in general.  There's always going to be some users who won't get it, but console on its own doesn't tell people a lot, and if its just a developer tool, it shouldn't be in the core.

Part of the goal with the UI rethink pegged for b1 is to allow better filtering/display.  If users don't get what something is, we should have a way for them to figure it out, not name it something scary so they won't touch it.
(Assignee)

Comment 29

11 years ago
Mike, are we just changing the ui or even all of the commands that are called? Like the following (specifically the omcommand line)?

-              <menuitem id="javascriptConsole" 
-                        label="&javaScriptConsoleCmd.label;" accesskey="&javaScriptConsoleCmd.accesskey;"
+              <menuitem id="errorConsole" 
+                        label="&errorConsoleCmd.label;" accesskey="&errorConsoleCmd.accesskey;" 
                         oncommand="errorConsole();"/>

Comment 30

11 years ago
Indeed, it is certainly not an 'error' console. I agree with comment #27.
For what it's worth, I'm with mconnor on this one -- "Error Console" is the name that makes the most sense, esp. if the default settings are to show errors but not warnings.  Note that "Script Console" would be quite a lie, since we show all sorts of other errors (XML parsing errors come to mind) there.
(Assignee)

Comment 32

11 years ago
So do we just want the UI/labels changed to say Error Console or also all of the commands and stuff like 'toJavaScriptConsole()' or just leave those be so that only the UI is changed?

Updated

11 years ago
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
At least for now, there's no reason to change the function names.
Version: unspecified → 2.0 Branch

Comment 34

11 years ago
(In reply to comment #31)
> Note that "Script Console" would be quite a lie,

Ok, so we rule out 'script console'. But why not 'developer console' or just 'console' or 'message console'?
Target Milestone: Firefox 2 beta1 → Firefox 2 alpha2
Version: 2.0 Branch → unspecified

Comment 35

11 years ago
(In reply to comment #34)
> Ok, so we rule out 'script console'. But why not 'developer console' or just
> 'console' or 'message console'?

As already said in comment #17:
"Developer Console" raises the question why developer tools are included in the default distribution (which AFAIK is because we want users being able to report errors - so rather "Debugger Console" which however sounds too geeky).

"Console" doesn't further allow to make a distinction to the system console (invoked through the -console command line parameter) or the rarely used Java console.

And "Message Console" is IMO only second choice since "message" is ambivalent (for one all errors/warnings/messages and for the other just the harmless/uninteresting messages) - and the default is and will continue to be to only show errors at first.
Target Milestone: Firefox 2 alpha2 → Firefox 2 beta1
(Assignee)

Comment 36

11 years ago
Created attachment 221502 [details] [diff] [review]
Rename to error console
Attachment #208757 - Attachment is obsolete: true
Attachment #208759 - Attachment is obsolete: true
Attachment #221502 - Flags: ui-review?(beltzner)
Attachment #221502 - Flags: review?(mconnor)

Comment 37

11 years ago
(In reply to comment #36)
> Created an attachment (id=221502) [edit]

From comment 21, "The menuitem ids shouldn't change though, so extensions targeting bits are less likely to change."
(Assignee)

Comment 38

11 years ago
Created attachment 221505 [details] [diff] [review]
Updated patch

Thanks dean, forgot about that.

Doesn't change menuitem id's
Attachment #221505 - Flags: ui-review?(beltzner)
Attachment #221505 - Flags: review?(mconnor)
(Assignee)

Updated

11 years ago
Attachment #221502 - Attachment is obsolete: true
Attachment #221502 - Flags: ui-review?(beltzner)
Attachment #221502 - Flags: review?(mconnor)
Version: unspecified → 2.0 Branch

Comment 39

11 years ago
I vote for Error Console.

I understand that in programming terms, errors are usually fatal, but I prefer the human semantics of the word, where anything showing in this console signifies an 'error' on the part of the web designer or indeed the browser itself when coming across unrecognised attributes etc.  I think the majority here like this term the most.

I also agree with the default view settings to show only JavaScript and Errors.
Attachment #221505 - Flags: ui-review?(beltzner) → ui-review+
Comment on attachment 221505 [details] [diff] [review]
Updated patch

r=me on the browser/toolkit bits

bz, this changes a bunch of stuff in core-ish areas, can you double-check these are ok?
Attachment #221505 - Flags: superreview?(bzbarsky)
Attachment #221505 - Flags: review?(mconnor)
Attachment #221505 - Flags: review+
Comment on attachment 221505 [details] [diff] [review]
Updated patch

sr=bzbarsky.  Gotta love the different accesskeys in different overlays...
Attachment #221505 - Flags: superreview?(bzbarsky) → superreview+
Neil, we might want similar changes to Seamonkey.

Comment 43

11 years ago
(In reply to comment #42)
>Neil, we might want similar changes to Seamonkey.
Hmm, the patch already changes suite help; incorrectly as it happens...
hm, is the chatzilla change correct?

Comment 45

11 years ago
Most certainly not.
(Assignee)

Comment 46

11 years ago
(In reply to comment #43)
> (In reply to comment #42)
> >Neil, we might want similar changes to Seamonkey.
> Hmm, the patch already changes suite help; incorrectly as it happens...
>

(In reply to comment #44)
> hm, is the chatzilla change correct?
>
Can you guys please elaborate? (In reply to comment #45)
> Most certainly not.
> 
 

Can you guys please elaborate?

Comment 47

11 years ago
The ChatZilla change is changing something that does NOT reference the JavaScript Console.

-msg.client.opened     = JavaScript console for ``*client*'' opened.
+msg.client.opened     = Error Console for ``*client*'' opened.

Note that the 'c' is not capitalised. The message is used in reference to a specific view you can open in ChatZilla that allows (among other things) arbitrary execution of JavaScript. It is *a* JavaScript console, not *the* JavaScript Console. Subtle, perhaps, but very definately an incorrect change.

Comment 48

11 years ago
Comment on attachment 221505 [details] [diff] [review]
Updated patch

>Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
>-  <h3 id="javascript_console">JavaScript Console</h3>
>-  <p>Opens the JavaScript Console, which tracks problems with JavaScript code.
>+  <h3 id="javascript_console">Error Console</h3>
>+  <p>Opens the Error Console, which tracks problems with JavaScript code.
Please also change the corresponding toc entry (just the nc:name):
http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331

Firefox Help is indeed in browser/locales.
Seamonkey (Suite) Help is in extensions/help. Those changes are incorrect since you didn't change the console for Seamonkey. See
http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd#16
http://lxr.mozilla.org/seamonkey/source/xpfe/components/console/resources/locale/en-US/console.dtd#38
(Assignee)

Comment 49

11 years ago
(In reply to comment #47)
> The ChatZilla change is changing something that does NOT reference the
> JavaScript Console.
> 
> -msg.client.opened     = JavaScript console for ``*client*'' opened.
> +msg.client.opened     = Error Console for ``*client*'' opened.
> 
> Note that the 'c' is not capitalised. The message is used in reference to a
> specific view you can open in ChatZilla that allows (among other things)
> arbitrary execution of JavaScript. It is *a* JavaScript console, not *the*
> JavaScript Console. Subtle, perhaps, but very definately an incorrect change.
> 

ok will submit a new patch to remove the chatzilla specific changes.

(In reply to comment #48)
> (From update of attachment 221505 [details] [diff] [review] [edit])
> >Index: browser/locales/en-US/chrome/help/menu_reference.xhtml
> >-  <h3 id="javascript_console">JavaScript Console</h3>
> >-  <p>Opens the JavaScript Console, which tracks problems with JavaScript code.
> >+  <h3 id="javascript_console">Error Console</h3>
> >+  <p>Opens the Error Console, which tracks problems with JavaScript code.
> Please also change the corresponding toc entry (just the nc:name):
> http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
> 
> Firefox Help is indeed in browser/locales.
> Seamonkey (Suite) Help is in extensions/help. Those changes are incorrect since
> you didn't change the console for Seamonkey. See
> http://lxr.mozilla.org/seamonkey/source/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd#16
> http://lxr.mozilla.org/seamonkey/source/xpfe/components/console/resources/locale/en-US/console.dtd#38
> 

Are the Seamonkey changes wanted?

Comment 50

11 years ago
The error I spotted was that "Error Console" should be indexed under "E".
(Assignee)

Comment 51

11 years ago
(In reply to comment #50)
> The error I spotted was that "Error Console" should be indexed under "E".
> 

What do you mean by that? Are the help docs indexed alphabetically?

Comment 52

11 years ago
(In reply to comment #49)
>Are the Seamonkey changes wanted?
Yes please, particularly as we'll be switching to the toolkit error console anyway. Note that I wouldn't bother changing any entity names, just values.
(Assignee)

Comment 53

11 years ago
Created attachment 222408 [details] [diff] [review]
this should do it

(In reply to comment #52)
> (In reply to comment #49)
> >Are the Seamonkey changes wanted?
> Yes please, particularly as we'll be switching to the toolkit error console
> anyway. Note that I wouldn't bother changing any entity names, just values.
> 
done

(In reply to comment #47)
> The ChatZilla change is changing something that does NOT reference the
> JavaScript Console.
> 
> -msg.client.opened     = JavaScript console for ``*client*'' opened.
> +msg.client.opened     = Error Console for ``*client*'' opened.
> 
> Note that the 'c' is not capitalised. The message is used in reference to a
> specific view you can open in ChatZilla that allows (among other things)
> arbitrary execution of JavaScript. It is *a* JavaScript console, not *the*
> JavaScript Console. Subtle, perhaps, but very definately an incorrect change.
> 
chatzilla changes removed
Attachment #221505 - Attachment is obsolete: true
Attachment #222408 - Flags: ui-review?(beltzner)
Attachment #222408 - Flags: superreview?(bzbarsky)
Attachment #222408 - Flags: review?(mconnor)

Comment 54

11 years ago
Comment on attachment 222408 [details] [diff] [review]
this should do it

You still haven't fixed the Table of Contents of Firefox Help:
http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
That is displayed in the sidebar of the Help Viewer. Just expand Menu Reference->Tools and note that there's still a "JavaScript Console" entry.

You also didn't address Neil's comment about this file being sorted alphabetically, so "Error Console" should be listed under "#e", not "#j":
http://lxr.mozilla.org/mozilla/source/extensions/help/resources/locale/en-US/help-index1.rdf
Attachment #222408 - Flags: ui-review?(beltzner)
Attachment #222408 - Flags: superreview?(bzbarsky)
Attachment #222408 - Flags: review?(mconnor)
Attachment #222408 - Flags: review-

Comment 55

11 years ago
Comment on attachment 222408 [details] [diff] [review]
this should do it

It would be nice if you could change xpfe's access key to 'C' too, thanks.
(Assignee)

Comment 56

11 years ago
Created attachment 222555 [details] [diff] [review]
Again

(In reply to comment #55)
> (From update of attachment 222408 [details] [diff] [review] [edit])
> It would be nice if you could change xpfe's access key to 'C' too, thanks.
> 

Done

(In reply to comment #54)
> (From update of attachment 222408 [details] [diff] [review] [edit])
> You still haven't fixed the Table of Contents of Firefox Help:
> http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/help/firebird-toc.rdf#331
> That is displayed in the sidebar of the Help Viewer. Just expand Menu
> Reference->Tools and note that there's still a "JavaScript Console" entry.
> 
> You also didn't address Neil's comment about this file being sorted
> alphabetically, so "Error Console" should be listed under "#e", not "#j":
> http://lxr.mozilla.org/mozilla/source/extensions/help/resources/locale/en-US/help-index1.rdf
> 

Both done
Attachment #222408 - Attachment is obsolete: true
Attachment #222555 - Flags: ui-review?
Attachment #222555 - Flags: superreview?(neil)
Attachment #222555 - Flags: review?(steffen.wilberg)
(Assignee)

Updated

11 years ago
Attachment #222555 - Flags: ui-review? → ui-review?(beltzner)

Comment 57

11 years ago
Comment on attachment 222555 [details] [diff] [review]
Again

The Firefox Help changes are fine, thanks. But I can't review the other changes, so requesting review from mconnor again.
Attachment #222555 - Flags: review?(steffen.wilberg) → review?(mconnor)

Comment 58

11 years ago
Comment on attachment 222555 [details] [diff] [review]
Again

Note: malformed patch at line 27 [patch stops at this error so there may be more].

Should we rename -jsconsole too? Should we rename jsConsoleHandler to errorConsoleHandler?

If you're not going to patch suite help index then please volunteer someone else to do all of the help changes.
Attachment #222555 - Flags: superreview?(neil)
(Assignee)

Comment 59

11 years ago
(In reply to comment #58)
> (From update of attachment 222555 [details] [diff] [review] [edit])
> Note: malformed patch at line 27 [patch stops at this error so there may be
> more].
> 

Looks like that part of the patch bittrotted because of the change to Add-ons, will fix that tonight

> Should we rename -jsconsole too? Should we rename jsConsoleHandler to
> errorConsoleHandler?
> 

I donno. From what I understood, only change things like entity values and help docs. Not change functions, menuid's and all the other stuff.

> If you're not going to patch suite help index then please volunteer someone
> else to do all of the help changes.
> 
Did I not include the help changes for suite? becuase I can't find what your talking about. I donno if I missed checking those out or I forgot to patch the index. I know I changed the index in help-index1.rdf

If I missed it altogether I'm sorry, not intentionally not including suite stuff.

Going to post an updated patch tonight after a reply to this comment from you. 
(Assignee)

Updated

11 years ago
Attachment #222555 - Flags: ui-review?(beltzner)
Attachment #222555 - Flags: review?(mconnor)

Comment 60

11 years ago
I see it now; I had expecting the files to be in alphabetical order...

Comment 61

11 years ago
oops; indecision between "had expected" and "was expecting"
(Assignee)

Comment 62

11 years ago
(In reply to comment #61)
> oops; indecision between "had expected" and "was expecting"
> 

oh, I've just been adding to the original patch since I deleted all of the checked out files I had when I first created the patch. Didn't feel like re checking them out and creating an all new patch...a lot of checking out and editing. I don't download the whole source, just which ever files I need at the time for a patch.

So if everything is good then I will fix the bitrotted part tonight and resubmit tonight.
(In reply to comment #59)
> Looks like that part of the patch bittrotted because of the change to Add-ons,
> will fix that tonight

No, bitrotting doesn't explain "malformed patch" errors.

Comment 64

11 years ago
You should use "cvs co <files>" to checkout the files you need, then "patch -p0 < patchfile" to apply the patch, then "cvs diff -up8 <files>" to generate the patch.

Use "cvs co <files>" again to merge the latest changes from the server. CVS doesn't remove your modifications, but tries to merge them. If cvs can't resolve conflicts, you need to fix them by hand with an editor. And don't delete your local files again!
(Assignee)

Comment 65

11 years ago
(In reply to comment #64)
> You should use "cvs co <files>" to checkout the files you need, then "patch -p0
> < patchfile" to apply the patch, then "cvs diff -up8 <files>" to generate the
> patch.
> 
> Use "cvs co <files>" again to merge the latest changes from the server. CVS
> doesn't remove your modifications, but tries to merge them. If cvs can't
> resolve conflicts, you need to fix them by hand with an editor. And don't
> delete your local files again!
> 

ahhh I never knew I could locally apply a patch. I always thought I was to build myself with the patch attached to see the changes. Thanks and I will play around with that tonight and hope to have a final working patch tonight.

Comment 66

11 years ago
(In reply to comment #65)
>I always thought I was to build myself with the patch attached to see the changes.
That's still correct, but this technique can be useful e.g. when fixing bitrot.
(Assignee)

Comment 67

11 years ago
Created attachment 222690 [details] [diff] [review]
Next attempt

ok I re checkedout every file and created a new fresh patch. Got rid of some bitrot like no more webshell stuff and qute is gone in the toolkit now (those changes were in previous patch). Also, I talked to biesi on IRC and he said this patch applied fine with no errors

Hopefully this is it, thanks guys for putting up with me...still learning here.
Attachment #222555 - Attachment is obsolete: true
Attachment #222690 - Flags: ui-review?(beltzner)
Attachment #222690 - Flags: superreview?(neil)
Attachment #222690 - Flags: review?
(Assignee)

Updated

11 years ago
Attachment #222690 - Flags: review? → review?(mconnor)

Comment 68

11 years ago
Comment on attachment 222690 [details] [diff] [review]
Next attempt

Almost there, however I did find two issues which will need to be addressed before check in:

>Index: mozilla/extensions/help/resources/locale/en-US/help-index1.rdf
>      </rdf:li></rdf:Seq>
>+     <rdf:li>
>+       <rdf:Description ID="JSConsole"
>+         nc:name="error console"
>+         nc:link="developer_tools.xhtml#js_console"/>
>+     </rdf:li>
>    </nc:subheadings>
You have to be careful here: the </rdf:Seq> denotes the end of the section. Instead, your patch needs to look like this:
+     </rdf:li>
+     <rdf:li>
+       <rdf:Description ID="JSConsole"
+         nc:name="error console"
+         nc:link="developer_tools.xhtml#js_console"/>
      </rdf:li></rdf:Seq>
    </nc:subheadings>

>Index: mozilla/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd
>-<!ENTITY javaScriptConsoleCmd.label                             "JavaScript Console">
>-<!ENTITY javaScriptConsoleCmd.accesskey				"S">
>+<!ENTITY errorConsoleCmd.label                                  "Error Console">
>+<!ENTITY errorConsoleCmd.accesskey				"C">
>Index: mozilla/xpfe/components/console/resources/locale/en-US/console.dtd
>-<!ENTITY console.title "JavaScript Console">
>+<!ENTITY errorConsole.title "Error Console">
I did ask you not to change the names, only the values...
Attachment #222690 - Flags: superreview?(neil) → superreview+

Comment 69

11 years ago
(In reply to comment #68)
> I did ask you not to change the names, only the values...

I suppose you're only talking about the console.title bit and not about the javaScriptConsoleCmd.label one (which probably should be changed according to http://developer.mozilla.org/en/docs/Writing_localizable_code#Guidelines ).

Comment 70

11 years ago
OK, I guess you can change javascriptConsoleCmd to errorConsoleCmd, but in that case don't forget to patch the XUL file too!
(Assignee)

Comment 71

11 years ago
Created attachment 222783 [details] [diff] [review]
Another

(In reply to comment #68)
> (From update of attachment 222690 [details] [diff] [review] [edit])
> Almost there, however I did find two issues which will need to be addressed
> before check in:
> 
> >Index: mozilla/extensions/help/resources/locale/en-US/help-index1.rdf
> >      </rdf:li></rdf:Seq>
> >+     <rdf:li>
> >+       <rdf:Description ID="JSConsole"
> >+         nc:name="error console"
> >+         nc:link="developer_tools.xhtml#js_console"/>
> >+     </rdf:li>
> >    </nc:subheadings>
> You have to be careful here: the </rdf:Seq> denotes the end of the section.
> Instead, your patch needs to look like this:
> +     </rdf:li>
> +     <rdf:li>
> +       <rdf:Description ID="JSConsole"
> +         nc:name="error console"
> +         nc:link="developer_tools.xhtml#js_console"/>
>       </rdf:li></rdf:Seq>
>     </nc:subheadings>

Fixed

> 
> >Index: mozilla/xpfe/communicator/resources/locale/en-US/tasksOverlay.dtd
> >-<!ENTITY javaScriptConsoleCmd.label                             "JavaScript Console">
> >-<!ENTITY javaScriptConsoleCmd.accesskey				"S">
> >+<!ENTITY errorConsoleCmd.label                                  "Error Console">
> >+<!ENTITY errorConsoleCmd.accesskey				"C">
> >Index: mozilla/xpfe/components/console/resources/locale/en-US/console.dtd
> >-<!ENTITY console.title "JavaScript Console">
> >+<!ENTITY errorConsole.title "Error Console">
> I did ask you not to change the names, only the values...
> 

Oops, forgot about that when I started over; Reverted it back to console.title

(In reply to comment #70)
> OK, I guess you can change javascriptConsoleCmd to errorConsoleCmd, but in that
> case don't forget to patch the XUL file too!
> 

Fixed...Left it as errorConsoleCmd and also changed that in the xul file.

Donno if I was supposed to carry forward the superreview or not so I requested superreview again.
Attachment #222690 - Attachment is obsolete: true
Attachment #222783 - Flags: superreview?(neil)
Attachment #222783 - Flags: review?(mconnor)
Attachment #222690 - Flags: ui-review?(beltzner)
Attachment #222690 - Flags: review?(mconnor)

Updated

11 years ago
Attachment #222783 - Flags: superreview?(neil) → superreview+

Updated

11 years ago
Attachment #222783 - Flags: review?(mconnor) → review+
(Assignee)

Updated

11 years ago
Whiteboard: [checkin needed]
(Assignee)

Comment 72

11 years ago
Comment on attachment 222783 [details] [diff] [review]
Another

Can someone check this in on the trunk? Thanks

I don't have a clue on who to ask branch approval for so leaving a blank request.
Attachment #222783 - Flags: approval-branch-1.8.1?
(Assignee)

Updated

11 years ago
Attachment #222783 - Flags: approval-branch-1.8.1? → approval-branch-1.8.1?(mconnor)
Attachment 222783 [details] [diff] checked in on the trunk.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Keywords: uiwanted
Resolution: --- → FIXED
Whiteboard: [checkin needed]

Updated

11 years ago
Attachment #222783 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
Whiteboard: [checkin needed (1.8 branch)]
(Assignee)

Updated

11 years ago
Blocks: 339619
(Assignee)

Updated

11 years ago
Blocks: 339622
No longer blocks: 339619, 339622
Blocks: 339619, 339622
Attachment 222783 [details] [diff] checked in on the branch.
Keywords: fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)]
(Assignee)

Updated

11 years ago
Status: RESOLVED → VERIFIED
Keywords: verified1.8.1
Keywords: fixed1.8.1

Updated

11 years ago
Duplicate of this bug: 367397
Product: Firefox → Toolkit
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.