Closed Bug 409780 Opened 17 years ago Closed 17 years ago

In <sidebarOverlay.js>, 'Error: locale is undefined', opening a browser window

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
seamonkey2.0a1

People

(Reporter: sgautherie, Assigned: sgautherie)

References

Details

(Keywords: regression)

Attachments

(1 file, 2 obsolete files)

(Bv1a) Replace nsIPrefLocalizedString with nsIURLFormatter
3.06 KB, patch
Details | Diff | Splinter Review 
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122505 Minefield/3.0b3pre] (nightly) (W2Ksp4)

No bug.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122502 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Bug 297759 "caused" a regression, when opening a browser window:
[
Error: locale is undefined
Source File: chrome://communicator/content/sidebar/sidebarOverlay.js
Line: 985
]
Code is at
<http://mxr.mozilla.org/seamonkey/source/suite/common/sidebar/sidebarOverlay.js#955>

Probably triggered by the removal of
[
pref("intl.content.langcode", "chrome://communicator-region/locale/region.properties");
]
but I don't know why 'general.useragent.locale = en-US' (present in <about:config>) isn't used :-/


*****

Noticed while looking there: correctly align
[
981   } catch(ex) {
]
(In reply to comment #0)
>but I don't know why 'general.useragent.locale = en-US' (present in
><about:config>) isn't used :-/
See bug 409725.
(In reply to comment #2)
> (In reply to comment #0)
> >but I don't know why 'general.useragent.locale = en-US' (present in
> ><about:config>) isn't used :-/
> See bug 409725.

Ah :-/ (Duplicate.)

(In reply to comment #1)
> <http://mxr.mozilla.org/mozilla/search?string=intl.content.langcode>

Shouldn't bug 297759 have removed the following lines too ?
[
/suite/common/sidebar/sidebarOverlay.js,
    * line 972 -- locale = prefs.getComplexValue("intl.content.langcode",
    * line 976 -- debug("No lang code pref, intl.content.langcode.");
/suite/locales/en-US/chrome/common/region.properties,
    * line 7 -- intl.content.langcode=en-US
]
Depends on: 409725
We should just remove intl.content.langcode completely, it was only introduced for region packs, which we already killed in SeaMonkey.
This URL should be sent through urlformatter, which nicely replaces %LOCALE% with the chrome locale, and we can replace %SIDEBAR_VERSION% ourselves, if we even want to have it at all (I'm not sure what we want it for).
Oh, and BTW, we should replace that Netscape URL there with something we set up ourselves, we probably should file another bug for getting that in place - or we remove the whole web-fetched sidebar customization list functionality.
Per comment 4:
[
We should just remove intl.content.langcode completely, it was only introduced
for region packs, which we already killed in SeaMonkey.
]

I'll look into the other suggestions after this patch...
Attachment #294683 - Flags: superreview?(neil)
Attachment #294683 - Flags: review?(neil)
Blocks: 409861
Comment on attachment 294683 [details] [diff] [review]
(Av1) Obsoleted (by bug 297759) code removal

>+    locale = prefs.getComplexValue("general.useragent.locale",
>                                    Components.interfaces.nsIPrefLocalizedString);
As per bug 409725 this isn't a pref localised string any more, and you should get the locale from the chrome registry anyway (the url formatter does).
Attachment #294683 - Flags: superreview?(neil)
Attachment #294683 - Flags: review?(neil)
Attachment #294683 - Flags: review-
Adding Willie Reid to CC as former CC of bug 409861
In bug 409861 (currently duped to here) I'm seeing an empty sidebar when I try to open it with F9, while keeping the number of browser windows (one) unchanged. I see the same "Locale is undefined" error as you do, if I care to open the Error Console.

Notes:
1. To me, not having a sidebar deserves more than "normal" severity.
2. Since I'm on Linux, I suggest extending this bug to PC/All or even All/All.
Normal + Windows 2000 -> Major + All, per comment 9...
Severity: normal → major
OS: Windows 2000 → All
No longer blocks: 409861
Going further than Av1 patch, per comment 4 and comment 6.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2007122703 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

I removed the try+catch which seems useless now.
Note that |formatURLPref()| does
[
      } catch(ex) {
        Components.utils.reportError("formatURLPref: Couldn't get pref: " + aPref);
        return "about:blank";
      }
]
I wonder if we actually want that behavior/value, or if we should filter it out ?
Attachment #294701 - Flags: superreview?(neil)
Attachment #294701 - Flags: review?(neil)
Attachment #294683 - Attachment is obsolete: true
Comment on attachment 294701 [details] [diff] [review]
(Bv1) Replace nsIPrefLocalizedString with nsIURLFormatter

>+  url = url.toLowerCase();

I don't particularly like this, but I see we need it with the current (still existing and working) Netscape URLs. We probably can remove that when we are creating our own sidebar directory somewhere.
Neil, ping ?
Flags: blocking-seamonkey2.0a1?
Depends on: 386696
Yay! my sidebar (see comment #9) has come back (not later than) in the following build:

Mozilla/5.0 (X11; U; Linux i686; rv:1.9b3pre) Gecko/2008010802 SeaMonkey/2.0a1pre

And no more "locale is undefined" in the Error Console when I hit F9 to open the sidebar. (what I get is a number of "this.docShell is null" for chrome://global/content/bindings/browser.xml but my sidebar is functional again.

Thanks, guys! :-) :-) :-)
Not yet restored in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008010900 SeaMonkey/2.0a1pre
(In reply to comment #15)
> Yay! my sidebar (see comment #9) has come back (not later than) in the
> following build:
> 
> Mozilla/5.0 (X11; U; Linux i686; rv:1.9b3pre) Gecko/2008010802
> SeaMonkey/2.0a1pre

Odd, I'm not aware of any related fix in that build...
Can you double check ?

(In reply to comment #16)
> Not yet restored in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
> rv:1.9b3pre) Gecko/2008010900 SeaMonkey/2.0a1pre

(Sure. Bug 386696 patch was checked in at 2008-01-09 01:15 only...)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008010902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

(With that patch, the current bug is still there. As expected.)
(In reply to comment #17)
> (In reply to comment #15)
> > Yay! my sidebar (see comment #9) has come back (not later than) in the
> > following build:
> > 
> > Mozilla/5.0 (X11; U; Linux i686; rv:1.9b3pre) Gecko/2008010802
> > SeaMonkey/2.0a1pre
> 
> Odd, I'm not aware of any related fix in that build...
> Can you double check ?

Yes, my sidebar is back; but I notice that general.useragent.locale is "user set" to the empty string in about:config -- let's see if "resetting" it makes a difference... no, my sidebar is still there, and its search engine drop-down too. I didn't restart SeaMonkey after resetting that pref though (and when I do, it'll be the next nightly, which is now available).

I'm pasting the useragent-string (not hand-copying it), with the help of the MR-Tech Local Install extension, here it is (and now it's its default setting):

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010802 SeaMonkey/2.0a1pre
Then, Linux and Windows would have different behaviors regarding this bug !? :-|
(In reply to comment #19)
> Then, Linux and Windows would have different behaviors regarding this bug !?
> :-|
> 

It would seem so, especially since another Linux user declared on the newsgroup that his sidebar was back too. What shall we do? Revert the present bug to "PC/Win2K" or something?
Oh-oh! With the "default" UA, "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008010902 SeaMonkey/2.0a1pre" again hasn't got a working sidebar... just clearing general.useragent.locale changes nothing... let's see what happens if (after typing this comment) I restart SeaMonkey...
Yep, that was it! with general.useragent.locale set to the empty string at startup, I have a working sidebar.
well, having an empty string there is an error in the first place and might cause other problems, I guess.
Comment on attachment 294701 [details] [diff] [review]
(Bv1) Replace nsIPrefLocalizedString with nsIURLFormatter

>   var url = '';
Nit: don't need this empty string any more, and move the var down.
Attachment #294701 - Flags: superreview?(neil)
Attachment #294701 - Flags: superreview+
Attachment #294701 - Flags: review?(neil)
Attachment #294701 - Flags: review+
Bv1, with comment 24 update.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008010902 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

> I wonder if we actually want that behavior/value, or if we should filter it out
?

I checked that the "Customize Sidebar..." dialog loads fine with the <about:blank> value; only (silently) not loading the missing data of course...
Assignee: sidebar → sgautherie.bz
Attachment #294701 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Blocks: 409725
No longer depends on: 409725
Flags: blocking-seamonkey2.0a1?
Keywords: checkin-needed
Hardware: PC → All
Whiteboard: [c-n: Bv1a]
(In reply to comment #4)
> ourselves, we probably should file another bug for getting that in place - or

I filed bug 411526.
(In reply to comment #22)
> Yep, that was it! with general.useragent.locale set to the empty string at
> startup, I have a working sidebar.
> 
Just to report this is ditto in Win XP.

Checking in suite/common/sidebar/sidebarOverlay.js;
/cvsroot/mozilla/suite/common/sidebar/sidebarOverlay.js,v  <--  sidebarOverlay.js
new revision: 1.130; previous revision: 1.129
done
Checking in suite/locales/en-US/chrome/common/region.properties;
/cvsroot/mozilla/suite/locales/en-US/chrome/common/region.properties,v  <--  region.properties
new revision: 1.13; previous revision: 1.12
done
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [c-n: Bv1a]
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9b3pre) Gecko/2008011002 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

V.Fixed.

*****

(In reply to comment #15)
> (what I get is a number of "this.docShell is null" for
> chrome://global/content/bindings/browser.xml but my sidebar is functional
> again.

This is bug 404236.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b3pre) Gecko/2008011002 SeaMonkey/2.0a1pre

Still "empty" sidebar when restarting with browser.useragent.locale defaulted to en-US

I guess I'll have to REOPEN bug 409861
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: