Make the script debugger UI l10n-friendly

RESOLVED FIXED

Status

()

Firefox
Developer Tools
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: past, Assigned: past)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

The debugger UI must be properly internationalized like the rest of the developer tools. GCLI might be a good inspiration as it is also HTML-based. The proper location of the text files will be determined in accordance to bug 687851.

Updated

6 years ago
Blocks: 697762
This bug required another fx-team merge, in order to get the new l10n bits:

https://hg.mozilla.org/users/dcamp_campd.org/remote-debug/rev/f8176b9f68db
Assignee: nobody → past
Status: NEW → ASSIGNED
Created attachment 572506 [details] [diff] [review]
WIP

Converted everything but the iframe to get strings from resource files. This will need to be converted to xhtml AFAICT and I'll get to it next.

Comment 3

6 years ago
In bug 700036 we started moving our xhtml/html documents to xul-documents-with-html-as-the-default-namespace.  This helps solve a few things (such as ltr).
Depends on: 694538
Created attachment 572764 [details] [diff] [review]
Working patch

(In reply to Dave Camp (:dcamp) from comment #3)
> In bug 700036 we started moving our xhtml/html documents to
> xul-documents-with-html-as-the-default-namespace.  This helps solve a few
> things (such as ltr).

This is an interesting data point in our html vs. xul discussion. However, I propose we deal with that issue in a followup, in order to move quickly towards merging with m-c. If the debugger does indeed suffer from the same bug, I think it would be easier to get people like Ehsan to verify it using a nightly, rather than getting them to build remote-debug. Doing work in smaller chunks will also help with our growing patch queue and the merge conflicts we're encountering with Victor.
Attachment #572506 - Attachment is obsolete: true
Attachment #572764 - Flags: review?(dcamp)
Blocks: 692405
Created attachment 572776 [details] [diff] [review]
Working patch v2

Fixed a typo (Globel->Global).
Attachment #572764 - Attachment is obsolete: true
Attachment #572764 - Flags: review?(dcamp)
Attachment #572776 - Flags: review?(dcamp)
(In reply to Panos Astithas [:past] from comment #4)
> Created attachment 572764 [details] [diff] [review] [diff] [details] [review]
> Working patch
> 
> (In reply to Dave Camp (:dcamp) from comment #3)
> > In bug 700036 we started moving our xhtml/html documents to
> > xul-documents-with-html-as-the-default-namespace.  This helps solve a few
> > things (such as ltr).
> 
> This is an interesting data point in our html vs. xul discussion. However, I
> propose we deal with that issue in a followup, in order to move quickly
> towards merging with m-c. 

That followup could be bug 700639.

Comment 7

6 years ago
Comment on attachment 572776 [details] [diff] [review]
Working patch v2

Review of attachment 572776 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/devtools/debugger/content/debugger-overlay.js
@@ +227,5 @@
>        case "resource":
>          NetUtil.asyncFetch(url, function onAsyncFetch(stream, status) {
>            if (!Components.isSuccessCode(status)) {
> +            let view = this.getDebugger(gBrowser.selectedTab).DebuggerView;
> +            alert(view.getFormatStr("loadingError", [ url, status ]));

Can we drop this alert entirely?
Attachment #572776 - Flags: review?(dcamp) → review+
(In reply to Dave Camp (:dcamp) from comment #7)
> Comment on attachment 572776 [details] [diff] [review] [diff] [details] [review]
> Working patch v2
> 
> Review of attachment 572776 [details] [diff] [review] [diff] [details] [review]:
> -----------------------------------------------------------------
> 
> ::: browser/devtools/debugger/content/debugger-overlay.js
> @@ +227,5 @@
> >        case "resource":
> >          NetUtil.asyncFetch(url, function onAsyncFetch(stream, status) {
> >            if (!Components.isSuccessCode(status)) {
> > +            let view = this.getDebugger(gBrowser.selectedTab).DebuggerView;
> > +            alert(view.getFormatStr("loadingError", [ url, status ]));
> 
> Can we drop this alert entirely?

Yes, there is another one as well a few lines below. I've been meaning to take care of them after I update this part to use a fresh version from the Source Editor, after it lands. In fact I wanted to file a bug to extract these functions into a utility module. I'll convert them to Cu.reportError for now.

I'll do it as part of bug 700351, in order to avoid rebasing the rest of the patches in the queue, and the modularization patch in particular.
https://hg.mozilla.org/users/dcamp_campd.org/remote-debug/rev/60125dac74de
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.