Nice- I had just modified the jquery plugin I was using to not use
$.getJSON, but I'd rather use use it if I can. I'll give your modifications
a shot. If there's a bug on jQuery for this issue, you should post your
patch!

Thanks
--Jon

On Tue, Dec 15, 2009 at 6:57 PM, Marcos Aruj <[email protected]> wrote:

> Hey Jon,
>
> I just modified jQuery's source code to take into account the
> chrome-extension protocol when checking for successful XHR requests. I just
> posted this to my blog so you can download the modified jQuery lib from
> there. (Haven't written for some time now...)
>
> http://marcosaruj.com/archives/428
>
> I basically modified this part of the code:
>
> // Determines if an XMLHttpRequest was successful or not
>   httpSuccess: function( xhr ) {
>     try {
>       // IE error sometimes returns 1223 when it should be 204 so treat it
> as success, see #1450
>       return !xhr.status && (location.protocol == "file:" ||
> location.protocol == "chrome-extension:") ||
>         ( xhr.status >= 200 && xhr.status < 300 ) || xhr.status == 304 ||
> xhr.status == 1223;
>     } catch(e){}
>     return false;
>   },
>
> Hope it works for you and anybody else.
>
> Turned out to be nobody's fault :P
>
>
>
> On Tue, Dec 15, 2009 at 4:35 PM, Jon Stritar <[email protected]> wrote:
>
>> Just tested it -- same thing happens with file URLs -- I guess its a
>> jQuery bug.
>>
>> --Jon
>>
>>
>> On Tue, Dec 15, 2009 at 5:22 PM, Aaron Boodman <[email protected]> wrote:
>>
>>> I see!
>>>
>>> Ok, my mistake. So status is supposed to represent the HTTP status
>>> code. In the case of chrome-extension:// and file:// this concept is
>>> not defined. I guess the status is not changing in the way that jQuery
>>> expects, which is leading to this problem.
>>>
>>> You could test this by using the same file with a file:// URL. If the
>>> same problem occurs, it is probably a jQuery bug. If not, then perhaps
>>> a Chrome bug.
>>>
>>> - a
>>>
>>> On Tue, Dec 15, 2009 at 2:17 PM, Jon Stritar <[email protected]> wrote:
>>> > In my situation, the readyState was 4, but the status was 0... so I
>>> think
>>> > this may have been the same issue. If the status is 0, is that a chrome
>>> or
>>> > webkit bug? Maybe the status not changing as expected caused jQuery to
>>> jump
>>> > the gun and call the error callback early causing the responseText to
>>> be
>>> > partially complete.
>>> >
>>> > --Jon
>>> >
>>> > On Tue, Dec 15, 2009 at 5:14 PM, Aaron Boodman <[email protected]> wrote:
>>> >>
>>> >> You two are describing different problems:
>>> >>
>>> >> In Marcos' case the response status was 0 and there was no content. In
>>> >> Jon's case the response status was 4 and he got partial content. At
>>> >> least that is my understanding. Please correct me if I've got things
>>> >> wrong.
>>> >>
>>> >> Getting partial content is a really bad result, and it is hard for me
>>> >> to believe such a problem is in jQuery.
>>> >>
>>> >> - a
>>> >>
>>> >> On Tue, Dec 15, 2009 at 2:13 PM, Marcos Aruj <[email protected]>
>>> >> wrote:
>>> >> > Yes, I don't the problem resides in jQuery. It's just that a status
>>> = 0
>>> >> > is
>>> >> > not normal I guess... No idea how to overcome this other than
>>> changing
>>> >> > jQuery's code (and plugins') to not check for the status but I don't
>>> >> > like it
>>> >> > :P
>>> >> >
>>> >> > On Tue, Dec 15, 2009 at 4:07 PM, Jon Stritar <[email protected]>
>>> wrote:
>>> >> >>
>>> >> >> Yes, it seems to be an issue with jQuery's ajax calls. If I
>>> substitute
>>> >> >> their stuff out for a simple synchronous GET call the code works:
>>> >> >>
>>> >> >>       var req = new XMLHttpRequest();
>>> >> >>       req.open('GET', file, false);
>>> >> >>       req.send(null);
>>> >> >>       req.responseText;
>>> >> >>
>>> >> >> Has anyone had luck using jQuery to access chrome-extension or file
>>> >> >> urls?
>>> >> >>
>>> >> >> --Jon
>>> >> >>
>>> >> >> On Tue, Dec 15, 2009 at 5:04 PM, Marcos Aruj <
>>> [email protected]>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> I also had this problem using jQuery. I read some discussions
>>> saying
>>> >> >>> that
>>> >> >>> if the file is not served by a http server(file:/// for example),
>>> then
>>> >> >>> there's no status set (0). For jQuery for example, i get the
>>> >> >>> responseText of
>>> >> >>> the file correctly, but the status is 0. So many plugins and other
>>> >> >>> stuff act
>>> >> >>> as this is a failure, even if the content was correctly pulled.
>>> >> >>> Would be nice if chrome returns a status for chrome-extension://
>>> >> >>> request
>>> >> >>> or any internal ajax requests. Wyt?
>>> >> >>>
>>> >> >>> On Tue, Dec 15, 2009 at 3:09 PM, Aaron Boodman <[email protected]>
>>> wrote:
>>> >> >>>>
>>> >> >>>> I wonder if there is an embedded null. Do you mind sharing the
>>> file?
>>> >> >>>>
>>> >> >>>> - a
>>> >> >>>>
>>> >> >>>> On Tue, Dec 15, 2009 at 12:54 PM, Jon Stritar <
>>> [email protected]>
>>> >> >>>> wrote:
>>> >> >>>> > I'm trying to use a library that dynamically loads JSON files
>>> via
>>> >> >>>> > XMLHttpRequests. I'm hosting the files locally in the extension
>>> so
>>> >> >>>> > they're accessible via the chrome-extension URL. I'm using the
>>> >> >>>> > complete chrome-extension URL in the request (and if I paste it
>>> >> >>>> > directly into the browser it downloads the json file).
>>> >> >>>> >
>>> >> >>>> > The XMLHtttpRequest in the library keeps failing with the
>>> following
>>> >> >>>> > parameters (when the error callback is called):
>>> >> >>>> >
>>> >> >>>> >   readyState: 4
>>> >> >>>> >   responseText: this has the 2.5 lines of the file
>>> >> >>>> >   status: 0
>>> >> >>>> >   statusText: blank
>>> >> >>>> >
>>> >> >>>> > I can't find any other error messages. Any ideas? Why would
>>> only
>>> >> >>>> > 2.5
>>> >> >>>> > out of 54 lines be in the responseText? The responseText stops
>>> half
>>> >> >>>> > way through a string (no unusual characters there) and the JSON
>>> is
>>> >> >>>> > valid. Do I need to add permissions for this?
>>> >> >>>> >
>>> >> >>>> > (On Linux build 4.0.270.0)
>>> >> >>>> >
>>> >> >>>> > Thanks
>>> >> >>>> > --Jon
>>> >> >>>> >
>>> >> >>>> > --
>>> >> >>>> >
>>> >> >>>> > You received this message because you are subscribed to the
>>> Google
>>> >> >>>> > Groups "Chromium-extensions" group.
>>> >> >>>> > To post to this group, send email to
>>> >> >>>> > [email protected].
>>> >> >>>> > To unsubscribe from this group, send email to
>>> >> >>>> > [email protected]<chromium-extensions%[email protected]>
>>> .
>>> >> >>>> > For more options, visit this group at
>>> >> >>>> > http://groups.google.com/group/chromium-extensions?hl=en.
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>> >
>>> >> >>>>
>>> >> >>>> --
>>> >> >>>>
>>> >> >>>> You received this message because you are subscribed to the
>>> Google
>>> >> >>>> Groups "Chromium-extensions" group.
>>> >> >>>> To post to this group, send email to
>>> >> >>>> [email protected].
>>> >> >>>> To unsubscribe from this group, send email to
>>> >> >>>> [email protected]<chromium-extensions%[email protected]>
>>> .
>>> >> >>>> For more options, visit this group at
>>> >> >>>> http://groups.google.com/group/chromium-extensions?hl=en.
>>> >> >>>>
>>> >> >>>>
>>> >> >>>
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> Marcos Aruj Alvarez
>>> >> >>> Ingeniero de Software
>>> >> >>> -------------------------------
>>> >> >>> [email protected]
>>> >> >>> -----
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Marcos Aruj Alvarez
>>> >> > Ingeniero de Software
>>> >> > -------------------------------
>>> >> > [email protected]
>>> >> > -----
>>> >> >
>>> >
>>> >
>>>
>>
>>
>
>
> --
> Marcos Aruj Alvarez
> Ingeniero de Software
> -------------------------------
> [email protected]
> -----
>

--

You received this message because you are subscribed to the Google Groups 
"Chromium-extensions" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/chromium-extensions?hl=en.


Reply via email to