Last modified: 2014-07-30 23:34:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T61604, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 59604 - VisualEditor: Console shows "TypeError: jQuery1xxxxx is not a function" when cross-domain ajax request is aborted
VisualEditor: Console shows "TypeError: jQuery1xxxxx is not a function" when ...
Status: RESOLVED WONTFIX
Product: VisualEditor
Classification: Unclassified
Editing Tools (Other open bugs)
unspecified
All All
: Lowest enhancement
: ---
Assigned To: Krinkle
:
: 58364 68059 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-03 19:40 UTC by Rummana Yasmeen
Modified: 2014-07-30 23:34 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot (569.46 KB, image/png)
2014-01-03 19:40 UTC, Rummana Yasmeen
Details
Reproduced on 8th January (162.90 KB, image/png)
2014-01-08 19:54 UTC, Rummana Yasmeen
Details

Description Rummana Yasmeen 2014-01-03 19:40:50 UTC
Created attachment 14221 [details]
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
Comment 1 Rummana Yasmeen 2014-01-07 00:49:36 UTC
Not happening anymore.Possible fix for the bug might be: https://gerrit.wikimedia.org/r/#/c/102377/
as discussed with Moriel.
Comment 2 Rummana Yasmeen 2014-01-08 19:54:43 UTC
Created attachment 14258 [details]
Reproduced on 8th January
Comment 3 Rummana Yasmeen 2014-01-08 19:54:57 UTC
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
Comment 4 Rummana Yasmeen 2014-01-10 17:30:10 UTC
This issue is happening on mw.org too
Comment 5 Krinkle 2014-01-10 17:47:05 UTC
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.
Comment 6 Alex Monk 2014-06-13 19:50:14 UTC
(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.
Comment 7 Alex Monk 2014-06-13 20:10:09 UTC
Although I can't actually reproduce this error.
Comment 8 James Forrester 2014-06-13 21:29:27 UTC
Looks like we fixed this – possibly by resetting the search on open?
Comment 9 Krinkle 2014-06-15 11:05:24 UTC
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
Comment 10 Alex Monk 2014-06-16 23:11:34 UTC
I already had InstantCommons enabled, but couldn't reproduce it before. Looks like I can now.
Comment 11 Gerrit Notification Bot 2014-06-16 23:20:39 UTC
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
Comment 12 Gerrit Notification Bot 2014-06-17 17:29:58 UTC
Change 140044 merged by jenkins-bot:
Media search dialog: Only try to abort request if possible

https://gerrit.wikimedia.org/r/140044
Comment 13 Krinkle 2014-06-18 01:29:33 UTC
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.
Comment 14 Krinkle 2014-06-18 01:30:51 UTC
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.
Comment 15 Krinkle 2014-06-18 01:41:08 UTC
Also:
* Upstream jQuery: http://bugs.jquery.com/ticket/8744 (status: cantfix)
* Closely related upstream Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=707154 (status: NEW)
Comment 16 Rummana Yasmeen 2014-07-16 20:48:32 UTC
*** Bug 68059 has been marked as a duplicate of this bug. ***
Comment 17 Krinkle 2014-07-30 17:17:12 UTC
*** Bug 58364 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links