function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

ajax toolkit beta 3 firefox bug?

hello -

i'm working on an sControl using beta 3 of the ajax toolkit. when i execute the following query:

var qr = sforceClient.Query("Select Id, ProductId, TotalPrice from OpportunityLineItem where OpportunityId = '" + oppId + "'");

it fails in firefox. however, when i try the exact same query in internet explorer it works fine. the query also works fine using firefox or internet explorer with beta 1 and beta 2 of the ajax toolkit.

any idea as to why this fails for beta 3 on firefox?
Hi vander,

What are the results being returned when it runs successfully in IE? Is there an error being thrown in FF?
Hi Dave -

in IE it returns the query values as expected. in firefox i'm not getting an error, the code just seems to hang and stop executing. it's strange because if i use beta 2 the query executes normally in firefox and IE.
Did you work this out? I was thinking of trying Beta 3, but this gave me pause.

Thanks, Steve.
Hi Steve,

The version to use going forward is at I didn't get enough information from the other poster to determine any issues. The 3.3 version is the version to use and supports the upcoming release of API 7.0 as well as API 6.0.
Ron HessRon Hess
when porting beta1 and beta2 scontrol code to the new beta 3.3, there are a few differences to be aware of.

i'll post the ones i recall here, perhaps others can post their experiences

bean.getClassName() method --> becomes a var --> bean.className

also all the getISO Time() routines are now

more as i find em.
There are several minor pains to contend with, and I think there's one coding bug in the 3.3 beta that I'm running into.

1. Minor. sforceClient.onTiming() appears to be gone.

2. Informational. dltypeof() is now: Sforce.Util.dltypeof()

3. Informational. All objects are now access through Sforce as in:
var r = new QueryResult; is now: var r = new Sforce.QueryResult;

4. Pain in the butt. I'm using Firefox/Venkman for debugging external to the website. E.g. I'm not loading it as an S-Control to test it, but running it outside of the Salesforce instance.

The try-except block at line 724 of sforceclient.js fails every time (I haven't looked closely, but I wasn't sure where "Url" was supposed to come from) and the debugger dutifuly stops to let me know and I have to hit continue. This happens a *lot* and while it doesn't stop functionality, it's a pain. Any way around it?
try {
if (Url) {
this.req = new Url();
} catch(e) {}

5. Bug. More importantly, my Updates are messing up and I'm getting a failure "Object[i] has no properties". I think this stems from the code at line 1375:

if (returnValue.className = "array") {
if (objects.clearDirtyFlat) {
} else {
for (var i=0;i objects[i].clearDirtyFlag();

Which seems goofy. At the very least, I suspect that the Assignment in the If statment was meant to be a comparison. Note that we have similar code in the Upsert logic around line 1410 below.

So, I may have to back down to the previous version which is a pain.

I suppose I could put my own version of the sforceclient.js in my own script with fixes... so we'll see.

Any thoughts? Thanks, Steve.
Hi Steve,

I'll address each of the issues that you have enumerated. Some of these items will not be available till the after relase tomorrow evening.

1. The onTiming has changed. To use your own function for the on timing event create a function that takes 2 parameters. The first will be the name of the api operation, the second will be the elapsed time. Call the sforceClient.registerTimingCallback method passing the function you created above. As I was creating the samples below I noticed a bug, so this will apply after the launch.

var tc = function(o, e) {
document.getElementById("myTextArea").value += "\n" + o + ": " + e;

An alternative is to use the built in timerlog. To use the built in logging, you need to add ?browser=true to the script tag: This will include some diagnostic and browser support at but does so with a slight performance hit. An example of doing this is shown below.

sforceClient.timerlog = new Sforce.Logger("builtin", "Timer Log");;

This will create a floating div that shows timing information. You don't need to add any elements to your page to use this, but again does require the browser=true parameter on the script tag.

2. Correct, everything has been namespaced to prevent collisions.

3. Same applies for object creation.

4. For the Venkman issue, I think you can set the debugger to stop only on unhandled exceptions. Check the help for that tool.

By the way, the URL object is the Konfabulator version of XHR. The code is checking to see if it is being hosted by a widget by determining the existence of that object.

5. This is clearly a bug. The code should read
if (returnValue.className = "array") {
if (objects.clearDirtyFlag) {
} else {
for (var i=0;i objects[i].clearDirtyFlag();

This bug fix will be in the launch release (thanks and sorry for the error).
Hey Dave, thanks for the response.

1. The Venkman features don't treat the (URL) issue the way one would want, although Venkman is doing it properly I believe.

In Venkman you have two menu options...

Debug->Error Trigger->Ignore|Trace|Stop for Errors and
Debug->Throw Trigger->Ignore|Trace|Stop for Exceptions

In the code (which the posting system will try to mungle so I'll add "."'s) :
try {
....if (Url) {
........this.req = new Url();
} catch(e) {}

The debugger is catching an Error on the Url reference and reacting depending on the setting of the Debug->Error Trigger value. Since there is a catch() clause, it's not an uncaught exception, and the Debug->Throw Trigger setting doesn't come into play.

I can, of course, just set Error Trigger to Ignore or Trace, but for my own debugging I'd prefer it to Stop.

I wonder if there are other ways to check for this Url being valid, etc. without throwing the error?

Are many people using this toolkit in the Konfabulator environment?

2. I don't think your corrected code is correct. :-)

Missing closure on the loops, assignment in the "if" statement, etc.

I suspect some code is being lost due to the Community posting system and I'm not seeing it properly?

Thanks for the help, Steve.

P.S. As with many Ajax-like solutions, handling the "back" button is a mess. Do you guys have any plans to support any sort of framework, or any "Salesforcian" like suggestions on how we should handle it. I realize it's very application specific if we want to maintain history, etc. For my part I just want to intercept Back (and probably Backspace) and trigger my own function calls, but over time I could see wanting more.
I see in the beta 3.3 code that the loadClientScripts function has been commented out.

some items, such as some Sforce.Util.ToIsoDate functions, have been added to sforceclient.js, but others have not, such as Sforce.Calendar.CalendarControl. I tried to see if the other javascripts were in the beta 3.3 but they did not seem to be (I'm assuming that is part of the reason for the removal of the loadClientScripts).

I'm not quite sure on whether I should be using the beta3.3 reference for sforceclient.js and then loading the other javascript files manually on my own as I think they are necessary or whether I should be utilizing some other process (such as copy all the beta 3 files to my own documents directory and then copy the new beta 3.3 over the old sforceclient.js file).

do you have a recommendation?

To get the full version of 3.3 you need to add a parameter to the script tag (..lib/ajax/beta3.3/sforceclient.js?browser=true ). This will load the core part of the toolkit and the browser extensions part of the toolkit.