JavaScript strict warning: chrome://communicator/content/search/shared.js line 118: redeclaration of var cm dIndex JavaScript strict warning: chrome://communicator/content/search/shared.js line 120: redeclaration of var cm d JavaScript strict warning: chrome://communicator/content/search/shared.js line 122: redeclaration of var cm dResource JavaScript strict warning: chrome://communicator/content/search/shared.js line 146: redeclaration of var me nuItem JavaScript strict warning: chrome://communicator/content/search/shared.js line 182: redeclaration of var me nuItem JavaScript strict warning: chrome://communicator/content/search/shared.js line 257: redeclaration of var ur i JavaScript strict warning: chrome://communicator/content/search/shared.js line 264: redeclaration of var rd fNode

-> me

This patch does indeed fix the warnings, but it's not the best way to fix it, because the variable won't be declared in that for loop if it doesn't hit the other one first (which it won't)

patch is still flawed. reassigning.

Netscape nav triage team: as per Matt Fisher's pre-triage recommendation, this bug is nsbeta1-.

Can someone tell me what's wrong with the second patch? This patch is over a year old, and I'd like to see what I can do to get a good patch created for this bug. Strict JS warnings are my topic of the month. :)

reassigning matt's old bugs to default owner.

I'm taking this...

This patch is more or less a rewrite of shared.js. it fixes indentation, cleans up the code a bit, and removes var declaration from loops.

the same as attachment 82344 [details] [diff] [review], but cvs diff -uw'd

This patch removes a couple "var" I left behind, and does a little more code cleanup.

okay, I've done some more finetuning of the code, and rewritten a couple rotten bits :) I think this is good now. Or at least better. I also think this will need a little thorough testing to ensure there's no regressions here.

Okay, I havn't seen any obvious regressions in my tree...

while (popupNode.childNodes.length) popupNode.removeChild(popupNode.childNodes[0]); i think there's some reason to remove the last child instead of the first child -- talk to caillon or bz. var isupports = Components.classes["@mozilla.org/rdf/rdf-service;1"].getService(); if (!isupports) return false; var rdf = isupports.QueryInterface(Components.interfaces.nsIRDFService); prefer: var rdf = Components.classes["@mozilla.org/rdf/rdf-service;1"].getService(Components.inte rfaces.nsIRDFService); if it works. if (target_item && target_item.nodeName == "treeitem" && target_item.getAttribute('selected') != 'true') be consistent about " and ' var cmdArray = new Array(); personally, i'd prefer: var cmdArray = []; but that may or may not be stylistic.

Is there still being worked upon this bug? These warnings are pretty annoying. If noone else is interested I'd be willing to get the patch up to date...

Last time I checked, this code was current (of course, that is a long time ago) the problem here is that it's such a monster of a change, and I sort of faded out from actively hacking on mozilla... shared.js also has seen next to no patches since the original version. Feel free to grab the bug, I won't return to working on mozilla bugs for the forseeable future.

Taking. shared.js is also responsible for the missing context menu in the search results window --> spinning off bug 195885.

-> Karsten, per his request

During this patch I discovered that the context menu of the multi-engine-search results couldn't be created because of the changes in the tree widget (-> bug 195885), so this is fixed in this patch, too. But bug 147068 (double entries in the search results) caused Mozilla to crash (the core xpfe\components\search\src\nsInternetSearchService.cpp can't handle non-existing tree nodes), so I had to fix that one somehow, too. Since the reason for 147068 is bug 196057 (double fired onload event), my patch includes a workaround for 147068 until that one is fixed. That said, this patch would actually belong to bug 195885, but since that bug isn't confirmed and this patch is based upon the patches already attached here, I've put here. (patch follows)

patch incorporating bug 195885, bug 147068 (by working around bug 196057) and incidentally this bug 57654

Comment on attachment 117147 [details] [diff] [review] MultiPatch V1 Shuehan now works on search.

Karsten: in general it's better to keep patches seperated, since it narrows the scope and impact of the patch and makes it easier to read and understand (e.g. the hack to work around the double onload event problem). Go ahead and attach patches to each of the mentioned bugs seperately and request r=/sr= on them.

Okay, I will try to break this into parts, even though these bugs are ickyly entwined. Thx!

I've spun off bug 205440 for JS problems in internetresults.xul/js.

Stalling for Doron's changes in bug 233874.

*** Bug 230966 has been marked as a duplicate of this bug. ***

This patch attempts to focus only on the javascript strict errors and not the other bugs in the code which have either been or should be spun off to other bugs. The one exception is the changing of the calls to GetStringFromName to getString which fixes the display of the sidebar context menu's Disable/Enable advanced search options. Thanks.

Actually, the bugs reported here are fixed "collaterally" in my patch for 195885. Alas, that is rotting for review for nearly four weeks now... :-/

Comment on attachment 175153 [details] [diff] [review] patch Clearing the reviews and obsoleting the patch since bug 195885 takes care of this bug as well as others and already has a patch.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420

The move to OpenSearch would probably invalidate this bug anyway.