frustrating error setting key in chrome

[Wormopolis]

Firefox and IE are pushing the key without any issues.  but in chrome, the key value isnt changing.  in console log I see this:

error An AJAX request may have been interrupted.
DOMException {message: "A network error occurred.", name: "NetworkError", code: 19, stack: "Error: A network error occurred.? at Object.sen…//d.storage.proboards.com/f/forum_106.js:1865:68)", INDEX_SIZE_ERR: 1…}

Object {readyState: 0, setRequestHeader: function, getAllResponseHeaders: function, getResponseHeader: function, overrideMimeType: function…}


I dont think its a size thing because Im not changing the actual key size, Im changing a value in in an object by 1, then setting the same key (plus increment) back:


       for (hc=currCloud.length-1; hc>=0; hc--) {
           if (currCloud[hc].tagword==wordtags[ww].replace(/\#|\[HASH\]|\s|\&nbsp;|<br(\s?\/)?>/gi,'').toLowerCase()) {
               wordtags[ww]='';
               foundcountMaster=true;
               currCloud[hc].tagcount+=com;
               if (currCloud[hc].tagcount<=0) currCloud.splice(hc,1);
               alert(currCloud[hc].tagword +' '+currCloud[hc].tagcount+'='+hc);
               break;
           }
       }



       console.log(JSON.stringify(currCloud));
       pb.plugin.key('Wormocode_hashcloud').set({value:currCloud, success:function() {alert('said it did');}, error:function() {alert('wtf');}});        
       alert('is it skipping this?');


ignoring the alerts that are there to help me see setpoints, in chrome however, it never calls the success or error functions.  I can see the currCloud array HAS been altered when I see it appear in the console.log, but after the page refresh the key remains unchanged.  firefox and IE show the updated data though.

any ideas?

[Tim Camara]

If you examine the outgoing request in the network panel, is the request well formed and the data you expect it to be?

[Wormopolis]

It would be a "post" right?

[Tim Camara]

Yeah, key sets are always posts.

[Wormopolis]

according to chrome network, it never even calls it?

I will play around with it more tonight. I know I CAN set a key in chrome because chess is still working. and the same line that isnt working in chrome now is working in firefox and ie

[Chris]

Assuming you are trying to set the key just before the page unloads, wouldn't this be related to the problem discussed here and in previous discussions?
Disabling the asynchronous mode enables a completion of an XHR in Chrome in this situation

Stackoverflow:doing AJAX safely on onunload / onbeforeunload said:

In my tests Chrome (and I guess as any other webkit browser probably) is UNABLE to perform an AJAX request BEFORE leaving a page.

Imagine for instance, that you need to clean up something on the server because the user clicked on some link or left the page.

First thing I noticed is that window.onunload DOES NOT work anyhow on Chrome (Webkit?)

Once you are using window.onbeforeunload MAKE SURE you DON'T put in the the body like this: Cause it is ignored. YOU HAVE TO do window.onbeforeunload=function() {...} to make sure the binding is done (or use jquery or protoype libs for this)

WITHIN your onbeforeunload code a ASYNCHRONOUS Ajax like this WON'T work either:

var req = new XMLHttpRequest();
req.open("GET", "dosomething.page");
req.send(null);

(although this will WORK in Firefox)

It will work if ONLY if the request is made SYNCHRONOUS like this:

var req = new XMLHttpRequest();
req.open("GET", "dosomething.page",false);
req.send(null);

Although keep in mind that synchronous can cause the browser to hang for 2minutes if the server does NOT reply.

Keep in mind that Proboards installs an onbeforeunload handler in order to check for pending AJAX requests related to things it needs to ensure gets saved (not plugin keys) but it is the very presence of these onunload/onbeforeunload handlers that triggers the unwanted behavior in Webkit from what I can tell in various bug reports. I had posted an "enlightening" article regarding this issue the last time it was visited and recommend reading if you haven't already done so if only to get a better view of the situation.

[Wormopolis]

and to get around that issue in chrome I started using decoys. I first search for the submit button of the form itself. the I create a new button, with the same value and class="decoy". then I hide the original button. then I bind a click event to the decoy button, which does all the key setting stuff I want it to do. in the key set event, I add a success callback. in that callback I tell it to send a "click" to the original button. then I append the decoy right before the original. so that it takes its place in the viewable DOM. like invasion of the body snatchers in a way.

user will click my decoy, my decoy will click the original button when its done. that way I dont have to worry about trying to race an AJAX request with a page event.

I have been using this method for 4 or 5 plugins now. and they all still seem to work.


however what is frustrating is my problem above isnt quite to the point of clicking the original.

you can see I set callbacks in that key set. neither call back is being called because the key set isnt happening in chrome. the alert immediately AFTER the line is firing however. in FF/IE, the callbacks are still firing. when I brought up the network tab like Tim wanted, I dont even see it calling the key set function (though I might not be looking in the right place, I have never used that tool before)

and in the addTag function itself, I literally put a

while (pb.ajax_active_requests()) {console.log('waiting./..');}

at the very end before it sends that click command to the original button. if its still waiting to do that key set, it would stall on that while loop, yet console.log has no "waiting..." in it.

I remember the article and it was inspired me to test out the decoy method. I even started updating the decoy to look for other decoys first so that if two plugins try to use them, the second plugin makes a decoy of the decoy. so all handlers are cascaded.

[Chris]

That workaround is still dependent on the AJAX response returning before the page unloads, the recommended solution is still to disable asynchronous calls (it has something to do with an immutable timer then being used that forces a waiting period for a timeout, stopping onload in its tracks). Remember that because of the presence of an onbeforeunload handler, Chrome views everything on the page as unimportant/expendable. If something on the page is important then Chrome believes it will be handled inside the handler itself so the handler if it exists is invoked and everything else is immediately prepared to be destroyed.

The fact that you're getting a "may have been interrupted" message is probably (and finally) acknowledgement by Chrome that the problem exists (there was never an error before, so this is new). I don't think a one-ended AJAX would appear in the network tab since it usually waits for a reply in order to have a status code to display with the request, if it was cut short then no reply may have been recorded, but make sure the persistent option is selected to preserve logs across page loads just in case. What I would try would be to set a breakpoint on the line that issues the AJAX request and manually turn off async then let her rip. If that then shows a key change in Chrome then we know what the problem is.

EDIT:

---

For those interested, the problem was not what is described above, it has to do with another webkit quirk where issuing a call from within a callback will fail if that call also has a callback of its own. This requires the hack of wrapping that call in a setTimeout so it initiates outside the callback routine else it will fail.
Google fails me however when searching for some official or even quasi-official report on this Chrome/Safari "bug", I just remember encountering it and finding a workaround documented in the Google Earth API.

[Wormopolis]

I think my problem is the "complete" call back in key.push doesnt work in webkit. its working in key.set though. I have multiple alerts set up and rewrote the entire function and even watching network in chrome I can see things not happening on the push callback. the page unload never even happens UNTIL the push callback fires it. and in chrome the page change never happens because of that.