https://bugzilla.wikimedia.org/show_bug.cgi?id=59604

Krinkle <krinklem...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|Unprioritized               |Lowest
            Summary|VisualEditor:"TypeError:    |VisualEditor: Console shows
                   |jQuery1830683983782510787_1 |"TypeError: jQuery_xxxxx is
                   |388777743220 is not a       |not a function" when
                   |function" appears while     |cross-domain ajax request
                   |searching for an image to   |is aborted
                   |add in an article           |
           Severity|normal                      |minor

--- Comment #5 from Krinkle <krinklem...@gmail.com> ---
Lowering priority as this is merely a console notice. It doesn't affect
anything in any way, it is in fact "expected" behaviour by jQuery due to there
not being another way to do what it does.

What it does is cancel a cross-domain ajax request. Short of CORS/XHR, there
isn't actually such thing as a cross-domain ajax request. What it really does
(and we rely on this) is JSON-P, which is a <script> tag to the api.php entry
point with a temporary function as callback (this is a sort-of standard method
called "JSON-P" which MediaWiki actively supports, it's not a VE intention or a
hack beyond what it is).

As with many ajax-based content population requests (e.g. search suggestions,
auto completion etc.) we abort pending requests when we fire off the next. When
interacting with the local API, we use regular XHR which has an abort method.

When interacting with a foreign API, jQuery gives us an XHR-like interface but
really underneath it is JSON-P, which means there isn't a way to actually abort
the request. Instead, jQuery deletes the callback and does a best-effort
approach to cancel the request. When the request does come back, it will try to
invoke a callback that has already been revoked, which results in a TypeError
in the asynchronous callstack of the ajax request.

This doesn't affect our callstack in any way, and from our perspective it works
as expected (after the request is aborted, our callback must not fire).

This last part is a jQuery internal implementation detail that might change in
the future, but either way, it is out of our hands, doesn't affect anything,
and nothing we can do anything about.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l

Reply via email to