Page MenuHomePhabricator

VisualEditor: Console shows "TypeError: jQuery1xxxxx is not a function" when cross-domain ajax request is aborted
Closed, DeclinedPublic

Description

Screenshot

Steps to reproduce:

1.Open a page with VE
2.Add any image
3.Open the dialog box to add image again
4.Type a different string in the textbox to search for matching images.

Observed Result:
An error appears TypeError: jQuery1830683983782510787_1388777743220 is not a function

See the screenshot attached
Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5
Page:http://en.wikipedia.beta.wmflabs.org/wiki/New_pageimage?veaction=edit


Version: unspecified
Severity: enhancement

Attached:

Details

Reference
bz59604

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 22 2014, 2:42 AM
bzimport set Reference to bz59604.
Ryasmeen created this task.Jan 3 2014, 7:40 PM

Not happening anymore.Possible fix for the bug might be: https://gerrit.wikimedia.org/r/#/c/102377/
as discussed with Moriel.

Created attachment 14258
Reproduced on 8th January

Attached:

This issue is still occurring while inserting image inside Media Settings and Reference Dialog.

Steps to reproduce:

1.Click on a image inside VE
2.Go to Media Settings
3.Type something as caption and add another image inside it

Second way to reproduce:

1.Click on a reference inside VE
2.Type something and add a image in this dialog box

Screenshot attached

Test Environment: http://en.wikipedia.beta.wmflabs.org/
Browser: FF 25
OS: MAC OS X 10. 8. 5
Page:http://en.wikipedia.beta.wmflabs.org/wiki/Jan8th?veaction=edit

This issue is happening on mw.org too

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.

(In reply to Krinkle from comment #5)

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.

I'm tempted to wontfix this, but apparently people are complaining that VE is broken because of it. I guess we'll just have to suppress the error.

Although I can't actually reproduce this error.

Looks like we fixed this – possibly by resetting the search on open?

This can be reproduced when using the input field for the Media insertion dialog.

E.g. on https://www.mediawiki.org/wiki/VisualEditor/Basic_example_worksheet?veaction=edit

It might not throw the error on your local wiki if your wiki is not configured to use a separate wiki, e.g. Wikimedia Commons, as extra file repository. Enable wgUseInstantCommons if you haven't already.

https://www.mediawiki.org/wiki/Manual:$wgUseInstantCommons

I already had InstantCommons enabled, but couldn't reproduce it before. Looks like I can now.

Change 140044 had a related patch set uploaded by Alex Monk:
Media search dialog: Only try to abort request if possible.

https://gerrit.wikimedia.org/r/140044

Change 140044 merged by jenkins-bot:
Media search dialog: Only try to abort request if possible

https://gerrit.wikimedia.org/r/140044

That patch, as far as I can see, did nothing. And if it did, it would actually have caused a regression.

The TypeError thrown is caused by the JSONP <script> tag request finishing and trying to invoke a temporary global function that jQuery exposed, but has revoked since because the consumer of $.ajax, VisualEditor in this case, has aborted the request.

All jqXHR objects have an abort method. Duck-typing it is useless because it is always there.

And while JSON-P doesn't have a native abort mechanism, jQuery does a good job of emulating it (it will do a best effort approach to cancel the http request for efficiency reasons, and in case it still makes it, it will make sure it reaches a dead end and not cause our application code to process its data[1]).

As I mentioned before, the dead end results in a Uncaught TypeError which sounds bad, but isn't, because it's in an asynchronous and independent call stack that has no influence on either our or jQuery's cod execution.

[1] Even if there was a way to not half-abort these requests, we wouldn't want that. We actually want these requests to reach a dead end. Otherwise we'd get race conditions where you type "a", "ab", "abc" and after "ab" is intended to be aborted, it might still arrive *after* "abc" and mess up our search results.

As such, please don't waste any more time on this. This is harmless errors that we can't do anything about and are side-effects of behaviour that is very much intended and wanted by us. Just another one the category of browsers being ugly and/or minor issues upstream.

Also:

  • Bug 68059 has been marked as a duplicate of this bug. ***
  • Bug 58364 has been marked as a duplicate of this bug. ***