when using the javascript debugger (I think)... Warning: assignment to undeclared variable LinkToolbarUI Source File: chrome://navigator/content/linkToolbarOverlay.js Line: 48

caused by bug: http://bugzilla.mozilla.org/show_bug.cgi?id=87428

qa -> claudius. Maybe caused by empty function declaration (I forget what the OO term for this is) for linkToolbarUI?

WFM after applying my patch for bug 102985.

*** This bug has been marked as a duplicate of 102985 ***

Whoops, wrong bug.

*** This bug has been marked as a duplicate of 102895 ***

this is not a dupe.... At least the warnings has NOT been fixed. I'm still seeing: Warning: assignment to undeclared variable hideMiscellaneousSeparator Source File: chrome://navigator/content/linkToolbarItem.js Line: 272 Warning: assignment to undeclared variable LinkToolbarUI Source File: chrome://navigator/content/linkToolbarOverlay.js Line: 50 Warning: assignment to undeclared variable showMiscellaneousSeparator Source File: chrome://navigator/content/linkToolbarItem.js Line: 266

I've seen these too. Could someone with JS knowledge comment on what needs to be done (in general terms) to get rid "undefined variable" warnings? I thought that in JS you could create a variable on the fly by assigning to it with no problems...

yes you can but you cant just to: <script> x = 1; </script> You gotta have: <script> var x=1; </script>

Tim, do you think you could take a look at this? I don't understand these OO conventions all that well, although I can fix the 2 errors in linkToolbarItem.js.

Yes I can, but I won't have time until this weekend.

what's the deal with these? LinkToolbarUI = function() showMiscellaneousSeparator = function() hideMiscellaneousSeparator = function() why not these? function LinkToolBarUI() function showMiscellaneousSeparator() function hideMiscellaneousSeparator() if there are no reasons, I'll attach a patch.

> if there are no reasons, I'll attach a patch. There's no reason that I can tell. Someone probably switched all function definitions to the "foo = function()" style believing they were making things consistent. The "foo = function()" style only applies to OO programming and prototype inheritance in JavaScript. Ultimately, the right solution is to switch to the "Foo.prototype = { ... }" style of defining classes. The current style is a holdover from when I was learning OO programming in JavaScript. Either way, the functions you pointed out aren't methods, so they should be defined using the latter syntax. Your patch gets r=Tool-Man, assuming I can give it. I was lazy and didn't test. I'm assuming it works for you?

my patch for bug 103097 also fixes these warnings; I'd personally rather see that go in than this one because it also fixes the perf issues. It's got review but it's waiting for sr and possibly approval if it's to make it for 0.9.7. Unfortunately I don't have the time to chase up sr at this point, but I'd love for someone else to. However, these changes look good to me too (although I have no time to test either). If you can find someone else to test the patch and make sure that it works, r=sballard@netreach.net if you want to check this one in instead of the 103097 patch. If you do check this one in, I'll re-diff that one.

Heh, basic's patch also would fix bug 110438 (which I just spent a minute writing a patch for using Patch Maker)

fixed in patch for bug 103097 *** This bug has been marked as a duplicate of 103097 ***

Verified dupe