[D7] Chrome 83 cancels jquery.form ajax requests over https

Thanks @catch

Reposting the D7 patch from #3138421-54: [D8] Chrome 83 cancels jquery.form ajax requests over https here.

Adding my test results from the other post here as well:

Tested the D7 patch from #54 on 7.69. All tests done over HTTPS.

Case 1: Unpatched
OSX Chrome 83: Ajax call got cancelled
Windows 10 IE11: Ajax call worked

Case 2: Patched
OSX Chrome 83: Ajax call worked
Windows 10 IE11: Ajax call worked

Did not test any other browsers.

I found an small problem in the patch on the D8 at #3138421-71: [D8] Chrome 83 cancels jquery.form ajax requests over https:

I found a small issue in the D7 patch:

+++ b/misc/jquery-ajaxsubmit.js
@@ -0,0 +1,55 @@
+        log('ajaxSubmit: skipping submit process - no element selected');

The log() function is undefined. This looks like it was copy-pasted from the jquery.form source code. This could probably be switched to console.log()?

Anyway, in it's current form, if I run jQuery().ajaxSubmit() in the dev console, I get a fatal error:

Uncaught ReferenceError: log is not defined

Here's a patch just switching log() to console.log().

Nice catch @dsnopek!

I wonder if we should just remove the "fast fail if nothing selected" lines and let the original ajaxSubmit handle that, as from there the log function (or whatever it gets minified to) is in scope.

I wonder if we should just remove the "fast fail if nothing selected" lines and let the original ajaxSubmit handle that, as from there the log function (or whatever it gets minified to) is in scope.

Yeah, actually, I think you're right and that that would be best. Looking at the jquery.form source some more it looks like this is the log function:

	function log() {
		if (!$.fn.ajaxSubmit.debug) {
			return;
		}

		var msg = '[jquery.form] ' + Array.prototype.join.call(arguments, '');

		if (window.console && window.console.log) {
			window.console.log(msg);

		} else if (window.opera && window.opera.postError) {
			window.opera.postError(msg);
		}
	}

That's quite a bit more sophisticated than just console.log() and will change behavior a little bit...

Here's a new patch that just removes the fast fail path.

I tested that it does the expected thing depending on the value of $.fn.ajaxSubmit.debug.

Via the magic of Browserstack, I tested this patch as working over HTTPS on the following browsers:

• Chrome 83
• Firefox 76
• Edge 81
• Safari 13.1
• IE 11
• Opera 68

I've applied and tested the patch on 2 D7 sites and confirmed that it resolved the issue (which I was seeing with Media WYSIWYG uploads as well as Paragraphs). Verified working in Chrome 83.0.4103.61, Safari 13.1 (14609.1.20.111.8), Firefox 76.0.1.

I've only seen this on one D7 site, when trying to use Paragraphs, but this patch works for me, too.

I have tested the in #8 and this fixes the issue in Chrome for me

I've tested the patch at #10 (3138421-54_d7.patch) on a D7.70 site and this fixes the issue in Chrome 83 for me.

I didn't see the problem in Firefox 76, but the patch didn't break anything there either.

The patch #8 fixes the issue for me as well.

Patch #8 works fine for me too!

Patch #8 is confirmed working for me but is there a reason why this line does not use a strict comparison?

if (typeof options == 'function') {

@dazweeja that line was copied from D7's version of jQuery Form:

https://github.com/jquery-form/form/blob/df9cb101b9c9c085c8d75ad980c7ff1...

It looks like later versions do use a strict comparison:

https://github.com/jquery-form/form/blob/v4.2.2/src/jquery.form.js#L121

So, yes we could probably change that.

Tweak to the patch to implement #17

Other than that, whitespace changes to try to match the v4.2.2 release of jQuery Form a little closer.

#19 works fine here.

Thanks,

Patch #19 fixes the issue in our case and it looks pretty good!

Thank you!

Tested Patch #19 on Chrome 83 (both Windows and Mac) and perfectly working.

Thanks!

Patch in #19 is working here as well (Chrome 83 + IE11).

Tested Patch #19 on Chrome 83 on Linux also working

Patch #19 fixed the issue on Chrome 83 for me. Thanks!

Patch #19 fixes the issue for me, Chrome 83 on Windows. A godsend. This was driving me nuts.

Some issue is going in chrome ver 83 but working in firefox. Also there's no /misc/jquery-ajaxsubmit.js file found in D7 : 7.70 release for patch. Please suggest ASAP.

Thanks!

Having trouble with the patch:

git apply 3143016-19.patch

3143016-19.patch:7: trailing whitespace.
/**
3143016-19.patch:8: trailing whitespace.
* Override jQuery Form's ajaxSubmit method in order to prevent it setting
3143016-19.patch:9: trailing whitespace.
* iframeSrc to javascript:false for https requests, because that no longer
3143016-19.patch:10: trailing whitespace.
* works with Chromium-based browsers.
3143016-19.patch:11: trailing whitespace.
* - https://www.drupal.org/project/drupal/issues/3138421
error: corrupt patch at line 87

EDIT: did
wget https://www.drupal.org/files/issues/2020-05-27/3143016-19.patch
rather than saving it in the browser. Patch works OK now.

I think overall the bug fix looks fine. Besides having concerns about not fully understanding the root cause for this regression, I only found few nitpicks:

1. +++ b/misc/jquery-ajaxsubmit.js
   @@ -0,0 +1,51 @@
   +(function (jQuery) {
   

   We usually rename jQuery to $ as a shorthand. I'm not sure we have an actual coding standard on this but it has been a pattern that we have followed pretty consistently.

2. +++ b/misc/jquery-ajaxsubmit.js
   @@ -0,0 +1,51 @@
   +      if (typeof options === 'function') {
   +        options = { success: options };
   +
   +      } else if (typeof options === 'string' || (options === false && arguments.length > 0)) {
   +        options = {
   +          'url': options,
   +          'data': data,
   +          'dataType': dataType
   +        };
   +
   +        if (typeof onSuccess === 'function') {
   +          options.success = onSuccess;
   +        }
   +
   +      } else if (typeof options === 'undefined') {
   +        options = {};
   +      }
   +
   +      options = jQuery.extend(true, {
   +        iframeSrc: 'about:blank'
   +      }, options);
   

   This all looks good. Maybe we could add a comment mentioning that this is direct copy of how the options object is created in the jquery.form library in https://github.com/jquery-form/form/blob/master/src/jquery.form.js#L141

@Parashram

If you want to apply the patch with the command "patch" in CLI, you should download the patch at the website's root path, then apply it with the -p1 parameter. I had same errors as you when I first tried with -p0 parameter, because the path was wrong.

You can run a test command this way : patch -p1 --dry-run < 3143016-19.patch
Then, if no errors are returned, you can apply it with : patch -p1 < 3143016-19.patch

By the way, the patch is working perfectly for me, thanks a lot !

I was experiencing an issue on a Drupal 7.70 site where an AJAX error was being thrown when trying to add a new paragraph.

Applying the patch in #19 fixed it for me.

RTBC++

How do you apply this patch manually if you don't have access to CLI? I don't see a /misc/jquery-ajaxsubmit.js file in the Drupal core file system for D7.

Any help would be greatly appreciated, I need to fix this for a client asap.

Scott

/misc/jquery-ajaxsubmit.js is a new file. Look the second line of the patch where is says "new file".

leymannx, thanks for the info, completely missed that :( I'll create a new file with the patch code and see how things play out. I appreciate the quick reply.

Scott

Is this a "permanent" change to Chrome or a bug? I do see Issue 1086008: current version breaks jquery.form post with iframe = true reported in the Chrome bugs list.

@Charles Belov: we won't know until that Chromium issue is closed, either the Chrome team may revert or provide a workaround in Chrome 84, or they may decide that this is required for e.g. a security fix and jQuery Form has to update.

The Chromium bug has been identified and a patch has been created:
https://bugs.chromium.org/p/chromium/issues/detail?id=1084874 (1086008, which specifically mentions jquery-form, was merged into this one).

Assuming this is going to be fixed in Chrome/Edge 84, should the shim still be published with Drupal Core, or?

Patch #19 fixes the issue on three different D7 sites for us.

+1.

Patch #19 fixes the ajax issues for all our D7.70 sites too! Great work!

Thanks all for testing - let’s get this in.

RTBM => Approved for merging.

Reading further ...

Given the impact that this has, there is a chance this might land in Chrome 83 even as a bug fix and I’ll contact the maintainer on github and see if we can make that happen.

Do we still want this workaround then, Community?

The earliest we can release this would be next Wednesday, the regular scheduled release window of 7.71.

Leaving as RTBC for now as we can still commit it.

I think we do want to commit a workaround for this in time for 7.71, because a lot of people will be on Chrome 83 for the next month or two.

I want to try a slightly different approach though. I'll post that soon.

#19 is very good. However, I'm concerned about overriding jQuery Form's ajaxSubmit() method, considering the different versions of jQuery Form that different sites might be on. Even though #19 looks to be compatible with the different versions, it's hard to really know, especially considering that the method signature changed in the different versions.

I don't think it's Drupal's responsibility to fix every possible way that jQuery Form's ajaxSubmit() can be called. I think it's only Drupal's responsibility to fix it for the way that Drupal calls it, and for that, we can rely on the Drupal.ajax API, which includes Drupal.ajax.prototype.beforeSerialize(). So this patch puts the necessary code into there.

Drupal.ajax.prototype.beforeSubmit() could also be used, but as that's currently documented as intentionally empty, I didn't want to change that.

Drupal.ajax.prototype.beforeSend() can't be used, because that runs after the iframe is already created.

Also, per #3138421-81: [D8] Chrome 83 cancels jquery.form ajax requests over https, I scoped this to target Chrome 83 only. Even though #3138421-82: [D8] Chrome 83 cancels jquery.form ajax requests over https links to an article saying that such stuff will get deprecated in the future, that hasn't happened yet, and we only need it to work for Chrome 83. As far as I know, all Chromium-based browsers (Edge, Brave, others?) send "Chrome/##" in their user agent in addition to whatever else they include. Though if someone knows of an exception to that, please comment with that.

No interdiff, because this is a new approach.

we can rely on the Drupal.ajax API, which includes Drupal.ajax.prototype.beforeSerialize()

There might be contrib/custom modules that stop this from getting called. For example, Panels IPE does. However, I think it's then their responsibility to apply the same fix in their custom handler, and they're not limited to only a single release window per month.

Doesn't need to be assigned to me anymore, but I'll respond to feedback, if any, tomorrow.

Maybe this is even better? Just moves it from beforeSerialize() to the Drupal.ajax() constructor.

Tested #19 and works for me.

Tested the #50 and works fine for me. Thanks effulgentsia !

@effulgentsia if Chrome 84 comes out and this hasn't been resolved from their part, will we have to fall back to the same issue again and change the pattern?

As you properly said, Drupal is "limited to only a single release window per month" which makes extra code more difficult to be added, especially for Drupal 7. On the other hand, I totally agree with you for your comment in #48: contrib modules should handle any occurring errors on their own.

My concern is that in Chromium's issue queue it is written that plan is to release it to 83 in about three weeks. This is a lot of time. I'd rather have a patch here - a patch which might not be committed but which will also play nice with any new Drupal 7 release - or add this to core. Just thinking out loud.

The approach in #50 looks great, thanks @effulgentsia!

I do, however, have some concerns about targeting the fix so narrowly at "Chrome/83."; the release schedule for D7 is actually for a bugfix release every 6 months, so after 2020-06-03 (next week) there isn't another planned until 2020-12-02.

We could do an unscheduled release if absolutely necessary, but I'd prefer to avoid "painting ourselves into a corner" if possible.

If we've concluded that the original reason for the javascript:false iframeSrc on https requests was for compatibility with older versions of IE (which seems very plausible), and it looks like the only currently supported version (IE11) doesn't actually require it... and other browsers seem to work fine without it... and about:blank is (to become) the standard...

I wonder whether we should be applying a UA-based condition at all? Or perhaps we could reverse the logic and only not apply the override for MSIE or something like that?

I think it's 2020 and supporting IE10 or lower should not be the target, to be honest. I vote for an unconditional patch. ie about:blank for everyone.

The next option is to make the opposite: check whether it's an old IE and apply javascript:false, if we really want to support the old IEs. The other benefit here is that UA string won't change for those old browsers and we do not need to track Chrome progress.

Thoughts?

Tested #19 and it didn't work for me. Tested #50 and it works great.

I was also facing this issue. I have applied the patch #50 now it's working fine. Thanks @effulgentsia for working on this issue.

Patch #50 doesn't solved it for me. Patch #19 worked very well for me.

Patch #50 doesn't include a update hook to force cache clears / rebuild of aggregated JS etc.. That could be one difference in terms of test results?

I'm still thinking about the relative merits of the different approaches to targetting the fix. I like #55 (i.e. override for everyone with an exception for old IE), but there is more potential risk as we'd be making a change for almost all browsers and that'd include ones we've not tested.

The patch in #50 did the job for me, thanks. But being scoped so narrowly to Chrome 83 worries me a bit as well. I mean, can we even be sure that 84 will work? Has anybody tried a nightly build or something like that?

To reassure ourselves that the javascript:false was put there to appease earlier versions of IE, I tested with IE6 on XP (which was a blast from the past, and meant setting up the webserver to support TLSv1 etc..)

With iframeSrc unconditionally set to about:blank the file upload over https worked, but IE gives you a mixed content warning in a dialog:

So I'm pretty confident now that's why the conditional is there.

I think that makes me feel better about overriding this for everything except old IE (perhaps checking for "MSIE" in the UA).

Any objections?

FYI updating jQuery Form Plugin also fixes the issue (and potentially any other future compatibility issues). Why not just updating it?

The only drawback is that it would also have to be updated in jquery_update module (for all its users to work).

👍 for Patch #50. Yes, the end user will need to clear the Chrome cache to get it to work.

Note: If an end user selected the "Upload" button with a file selected, the insert was made into the "file_managed" table and the file was added to the directory/folder associated with the "File" field. I had to manually delete the FID's that were not attached to a node as well as remove the files from the system folders.

Updating the plugin is definitely an option for individual sites.

I think updating the version in core is too risky in terms of potential regressions though.

@effulgentsia

Thanks for your effort.

Comparing #47 and #50 - there is a difference in condition
options.iframeSrc === 'javascript:false

Was it removed for a reason?
Having that condition seems a bit safer for me.

updating jQuery Form Plugin also fixes the issue

We'd have to update to version 3 or higher to get the fix, and that requires jQuery 1.5, and updating Drupal 7 core from jQuery 1.4 to 1.5 might introduce other breaking changes.

Comparing #47 and #50 - there is a difference in condition
options.iframeSrc === 'javascript:false
Was it removed for a reason?

By moving the code from beforeSerialize() to the constructor, it runs before ajaxSubmit() runs, so options.iframeSrc isn't set to anything yet.

I think that makes me feel better about overriding this for everything except old IE (perhaps checking for "MSIE" in the UA).

https://github.com/jquery-form/form/pull/572#issuecomment-632910005 reports that IE11 also fails on about:blank, but https://github.com/jquery-form/form/pull/572#issuecomment-634493670 disputes that. I don't know which to believe. Maybe the first poster was mistaken, or running in an old-IE mode, or having some other quirks in their particular use case?

I'm convinced though to broaden the fix to all non-IE browsers, so the only decision left is whether to include all versions, as per #19, or to only old ones for some definition of "old".

NW for broadening the user agent check.

In Slack, @mcdruid confirmed that he tested in IE11 and found no problems with about:blank there, so I guess +1 to special-casing only "MSIE". I'll upload a new patch, with updated code comments, in the next hour or two.

Another confirmation, I also tested IE11 with about:blank and it works fine.

Tested patch #50 on a site D7 with jQuery 1.9 (using jquery_update) and works fine on Chrome 83.0.4103.61 (Build oficial) (64 bits).

I personally would be okay to only target Chrome 83 as I am fairly sure that it will at least be fixed again in Chrome 84.

That said if the problem was created for IE6, etc. then it indeed has not much relevance more today.

I did the following tests:

Test 1:
OS: Kubuntu 20.04
Chrome: Version 83.0.4103.61 (Official Build) snap (64-bit)
Image file: Attached

Test 2:
OS: Windows 10 Pro Version 1903
Chrome: Versión 83.0.4103.61 (Build oficial) (64 bits)

Getting the same error.

I tested the patch #50 and works perfect on nginx and apache server running PHP 7.2 and mysql 5.3 or 5.7. jQuery version 1.9.1.

19 has worked for me so far testing w/ Chrome 83.0.4103.61 (Official Build) (64-bit) Still trying to decide whether to use this or #50

This broadens the change to apply to IE11 and all non-IE browsers. In other words, only IE 10 and less retain jQuery Form's javascript:false workaround. I updated the code comments accordingly.

This also adds the system_update_7084() function to cause a cache clear, as #19 had.

I personally would be okay to only target Chrome 83

Yep, it's a choice between managing risk by changing behavior for only the browser that's currently broken by HEAD (#50), vs. doing the semantically correct thing for all browsers that can handle it (this patch).

I could go either way on it, so leaving it up to @Fabianx to decide which to commit.

#50 worked for me. I did clear caches after applying

Patch #75 worked for me, thank you!

Patch #75 worked for me in my testing.

Is there consensus that this is the path we are going down or are we still weighing in on the method in patch #19?

Patch #75 works for me. Thanks.

I can confirm, that patch #75 is working for us. I hope it will be commited to the next release.

It took a while to set up a D7 site that worked properly over https on a variety of old IE versions; I think some of the JS changes made in the last few years may have caused problems with some older versions (but that's not in scope of this issue). I managed to get Drupal 7.10 working reliably over https on apache 2.2, and tested a range of old IEs with the about:blank change in ajax.js

My conclusion is that it only causes a problem in IE6, in that you get the mixed content warning as detailed in the comments in #75

IE7, IE8, IE9 and IE10 all seem to work fine with about:blank set unconditionally.

So it really looks like the javascript:false workaround is an anachronism.

We could update the comment in #75 to reflect that we've now tested IE 7-10, but other than that, I think it's what we should go with.

Some screenshots:

I updated the comment to reflect that @mcdruid tested IE 7-10.

Since it was just a comment change, I kept RTBC status. Please let me know if it should get pushed back to Needs Review.

Thanks, but I think the comment update in #82 is not quite right, as my testing suggests that it's only IE6 which requires the workaround.

Interdiff against #75 as that's what this is trying to update in light of further testing.

My mistake. Thanks for correcting this.

If this newer patch makes it into 7.71 will the system module have an empty hook_update to keep the schema in sync with those of us that applied earlier patches?

Ok I’m an idiot it is totally already in there! Don’t review patches on a phone!

Hello, thanks for the patches. What is the JQUERY version that you are using with these patches?

What is the JQUERY version that you are using with these patches?

#83 doesn't make any changes to jQuery code itself. It only affects the options that Drupal's ajax.js passes to jQuery Form's ajaxSubmit() function.

Drupal 7 core includes jQuery 1.4.4 and jQuery Form 2.52.

You can use jQuery Update to get later jQuery and jQuery Form versions.

This patch fixes the Chrome 83 bug regardless of whether you're using jQuery Update and/or which versions you select from there.

FYI for people following this issue: Per comment #24 of https://bugs.chromium.org/p/chromium/issues/detail?id=1084874#c24, the Chromium team released a fix to Chrome 85 (Canary) and is asking for test confirmation from people as to whether it resolves the issue and if it introduces new problems, so as to help them determine if it's ok merge into Chrome 84 and 83.

If anyone here is in a position to test their sites on Chrome Canary without this issue's Drupal patch applied and report your results to that Chromium issue, that would help them. And if you do discover a regression to your site with Chromium's fix, then reporting that to them will help prevent that regression from getting into a production release of Chromium.

It probably won't help them to get bombarded with a ton of comments that all test the same thing, but if you have unique information to report, then that's a big help. So far, I don't think anyone has reported there a test result of https file uploads on Drupal 7 on Chrome 85.

Okay, so I've got this problem in my D7.70 sites, currently without the patch applied, and tested them both on chrome 83 and Canary 85:

- Version 83.0.4103.61 (Official Build) (64-bit): FAILED, the problem occurs
- Version 85.0.4160.1 (Official Build) canary-dcheck (32-bit): the problem was FIXED, I was able to upload files once again.

Drupal 7 core includes jQuery 1.4.4 and jQuery Form 2.52.

You can use jQuery Update to get later jQuery and jQuery Form versions.

This is true, though I was getting 500 errors from AJAX until I cleared the cache a few times. That method now works (jQuery 2.1, Drupal 7).

I confirm that the latest Chrome Canary version (85.0.4161.0) fixes the Chrome 83 issue on a Drupal 7.70 site.

nice work everyone, thankfully Chrome 85 will fix this without any action required.

If I am understanding correctly that this is a Chrome bug not a Drupal bug that is fixed in Chrome 85; we can close this as 'works as designed'?

since, really, this is a browser bug not an application bug. Chrome has fixed this and those that encounter it will get the upgraded Chrome.

So nice that Ubuntu by default installs Mozilla Firefox and not Chromium.

@joseph.olstad Chrome 85 has release date in 3 months. It is still most used web browser and this issue affects all Drupal 7 sites (admin / frontend) where ajax uploads are used. I think it is very important to fix this despite the fact that this is a browser bug. I do not think people will change browsers just because of this bug, instead all anger will goes to Drupal side. We had to patch dozens of websites until today, because you cannot tell users: just change browser...

//edit: It affects all basic actions in Drupal CMS (content editing, etc.). You cannot even upload images in pages/articles because of this bug.

#19 patch working here. Using Drupal 7.70.

ah ok I didn't know the Chrome release schedule was so slow, yes by all means if we can resolve this without breaking anything, we should do so.

After internal consideration we have decided to fix this bug and change to the new behavior for all browsers except MSIE.

RTBM => Over to mcdruid for commit.

Thanks for all the testing.

A client reported a related problem with file attachments.

The patch fixes the problem, but posting more information below, in case anything else needs attention.

Will there will be a Drupal 7.71 release? I would prefer to not to be patching core on production sites.

---

I am able to upload files by saving a node rather than using the upload button, but when editing I could not remove files.

Steps to reproduce on simplytest.me

1. Spin up a Drupal 7 site
2. Add a file field to a content type
3. Create a new node with a file attachment.
4. Save the node without using the upload button.
5. Edit the node and try to remove the file using the remove button.

Confirm that this problem appears to effect Chrome 83. Edge, Firefox, Safari and Brave, were fine.

This will be in the next D7 release due in a couple of days.

Thanks for all the reviews and testing!

Just a note that the fix has apparently been back-ported to Chrome 83 and is expected to ultimately be released in Chrome 83 (83.0.4103.96 or newer), per Issue 1084874: async form submission change breaks site expecting first load event for just-created iframe to be for the form submission Comment 52 at Mon, Jun 1, 2020, 4:22 PM PDT

https://www.drupal.org/project/drupal/issues/3143016#comment-13654948

Worked for me !.
But anyways it will be soon in the new drupal update.

Regards,
Siva

The fix has been merged to Chrome 83 already:

The next rollout of 83 include the fix, look for version 83.0.4103.96 or newer.

I'm running

Google Chrome is up to date
Version 83.0.4103.61 (Official Build) (64-bit)

I guess it should be available for everyone in the next few days

Hello everyone! after update jquery.form error with cancelled status disappeared, but come up new error - any of ajax actions ends with AJAX HTTP error with code 200 (alert message). Does anyone have the same problem?

Is better waiting a official release of Drupal 7.x, or will take more time and the best approach is to apply the patch?

@dzerayeah

any of ajax actions ends with AJAX HTTP error with code 200 (alert message).

Can you get more information about this?
You can check:
- Console in developer tools, to check for javascript errors.
- Network tab in browser developer tools, to check the response being sent.
- Drupal error logs (watchdog).
- PHP error logs.

(I would suggest to not post the entire logs here, but look for a specific error message.)

Is this really a side effect of this patch?
Did you test it with and without this patch applied?

Can you try this in different browsers and compare?

(I am not sure if we need to open a new issue or reopen this one, but I think first we need more info)

Yes, i tried all of this:
1. console have not any errors with and without patch
2. Drupal watchdog have not any errors
3. php error log have not any errors too

Without patch:
1. ajax query cancelled (printscreen 1 and 2)
2. this error only in Google Chrome 83

With patch:
1. ajax query get status 200 (ok)
2. but i have alert message (printscreen 3) and nothing happens after that
3. this error in all browsers (Yandex, Chrome, Safari, IE)

Link to printscreens here https://drive.google.com/drive/folders/1QD79JZ3rHeenyYuddFeBAzZte7bHfcKW...

I have no idea why it's so. Please, help

Without the patch, which browsers, other than Chrome 83, show the error?

If all of them, then that suggests the patch just ensures Chrome behaves consistently (i.e. correctly shows the error).

Looks like the google drive link (#106) has access control set to exclude anon?

Is this a vanilla D7 install (guessing not)? Which versions of jQuery, JQuery Form etc... does it have?

@james.williams without patch error shows only in Chrome and only in v83

@mcdruid yes, sorry, thats right link https://drive.google.com/drive/folders/1QD79JZ3rHeenyYuddFeBAzZte7bHfcKW...
vanilla does not install, yes.
jQuery JavaScript Library v1.4.4 (only with this version drupal works correctly)
jQuery Form Plugin version: 2.52 (if without patch)

Sorry, my question wasn't actually very helpful. Thanks for sharing the screenshots now.

What happens on other browsers, without the patch?

I think it's about this: https://www.screencast.com/t/svAIMJmdt
It happens after the last core update, only on https ... and it seems in all browsers.

@james.williams on other browsers without patch all work great, without any errors, all ajax queries return success status (code 200)

@bogdanru do you mean that the problem in https? by the way, in sites with http this problem doesn't exist, but i have two sites with https and one of them have that problem, but another no have. May be the problem in php settings and hosting provider?

No, I think the problem is in the last update of drupal core and only if you use https. Maybe the website that it works for you with https is not updated yet? Or you didn't run update.php (clear cache)?

Site with https and with patch (and work great) have a Drupal core v.7.59
Site with https and with patch (that does not work, error with alert AJAX HTTP 200) have a Drupal core v.7.38

Do you mean that i have to update my site core?

There have been security releases for Drupal core that you are missing. You should upgrade immediately - see the latest release: 7.70

@james.williams Is it help to remove my problem or it's just need because of security?

I think we'd need to see the issue reproduced on a vanilla install of the latest version of Drupal core to be able to progress. Otherwise, there are too many other possible factors that could be causing your issue.

Confirm this happens to me with Chrome (83.0.4103.61) and Drupal 7.70.

Patch #83 works for me, and looks simple enough solution.

Thanks @MrPaulDriver - your reproduction message in post #97 is spot on. On my site, the user could not remove any images from nodes when using current version of Chrome (83). Firefox and Safari work performing the same task. In the Chrome development console it didn't show any JS errors, but showed the cancelled connection being fired when I clicked the 'remove' button on the image.

Also confirming that patch #83 works on our end. I removed the empty update hook though as it's unnecessary - a simple cache clear sufficed.

@james.williams i updated the core of drupal to v.7.70, but errors are still the same. Do you have any idea what i can do with that?

I can confirm the issue has been fixed on Chrome Version 85.0.4162.2 (Official Build) canary (64-bit)

I switched my admin theme jquery version to 2.1 and it seems to be working -- if you're only concerned with the admin theme I'd suggest trying to play around with the jquery version using the jquery update module, it may break something else on that theme, but it may be an okay compromise until chrome releases an update

Yes, if you're using a 7.x-3.x version (e.g., 7.x-3.0-alpha5) of jQuery Update, then selecting a version of jQuery that's 1.6 or higher will also give you jQuery Form 3.51, which circumvents this bug. Note, however, that the 7.x-3.x branch is still at alpha stability, so take that into consideration in deciding if you want to use it. The stable 7.x-2.x branch of jQuery Update does not give you the required version of jQuery Form to circumvent this bug, even if you select a jQuery version that's 1.6 or higher.

So the choices for people are any one of these, whichever works best for your situation:

• Use jQuery Update 7.x-3.0-alpha5 if you're ok with alpha modules and a jQuery version that's 1.6 or higher.
• Apply the #83 patch for now, and then unapply it prior to upgrading to Drupal 7.71 when that comes out tomorrow.
• Wait till tomorrow, and then upgrade to Drupal 7.71. Use a browser other than Chrome in the meantime.
• Wait till Chrome rolls out the newer build of Chrome 83 that fixes this.

Meanwhile, if anyone is able to reproduce @dzerayeah's issue, or any other issue with the #83 patch, please report that. Thanks!

#83 patch fixed for me on drupal 7.70. Thank you!!

@dzerayeah: Can you post a screenshot that includes the entire alert message? It looks like the printscreen3 that you posted is only showing the first 3 lines of the response text.

@effulgentsia yes, i uploaded printscreens 4-6 here https://drive.google.com/drive/folders/1QD79JZ3rHeenyYuddFeBAzZte7bHfcKW...

#83 works fine.

@dzerayeah: Maybe it is something in your ajax callback since the request is not canceled. Maybe post your entire ajax callback, but I think it is out of the scope here.

@dzerayeah - To help identify/eliminate that possibility, can you perhaps set up a clean Drupal install, with the paragraphs module? The issue can be fairly easily reproduced (once a paragraph type & field is set up on a content type) on Drupal 7.70 - see #3138378: Chrome 83 cancels /system/ajax calls on paragraph add/remove for the description.

@james.williams unfortunately, i can not do this, because my problem is reproduced only on production server. My test server does not show this problem. More than that, my test server works well with Chrome 83 and without patch jquery.form. So, can it be the problem with php version or any server settings?

Can anyone please be so kind and share on pastebin the 2 patched files ajax.js and system.install ?

I cannot patch them manually and do not have ssh, only ftp but we urgently need a fix for Chrome

@twelvell Drupal 7.71 is now available, and includes the fix. Or if really needed, you could take the files direct from the source.

@dzerayeah if your test server does not show the problem, then sure - there may well be some other difference causing your issue.

@james.williams thanks

I am getting an error message when they try to upload a file Drupal 7.x
When I tried in Firefox on my Mac it worked correctly.
In Safari it worked only some time.
In Chrome it does not work at all.

Thanks in advance.

@testingmai6 what versions of Drupal and Chrome are you using please, and are you using any of the patches from this issue? Today's release of Drupal 7.71 includes the fix produced in this issue.

D7.7.1 update works! Thanks to all who got this out quickly when this emerged.

An additional obvious area to check: keep in mind same update needs to be applied to ajax.js in Jquery Update contrib module if you're using that in your site backend, too.

I initially applied D7.7.1 and forgot that that module directly overwrote the updated changes to ajax.js. Re-applied the same code to ajax.js in that module and all forms worked again in Chrome 83...

ajax.js in Jquery Update contrib module

Which version of jQuery Update still has an override of ajax.js?

@dzerayeah: can you open a new issue and then add a comment here linking to it? Then we can continue trying to figure out your unique case there.

@effulgentsia I wasn't on the alpha channel for Jquery Update after applying D7.7.1. Was still on the 7.x-2.7 branch and noticed the issue was still present for me via HTTPS.

FYI jquery upload was broken by the 19-02-2020 Chrome browser update 83.0.4103.61.
https://bugs.chromium.org/p/chromium/issues/detail?id=1084874
Fixed in release from 03-06-2020 (83.0.4103.97)... phew.

@gabrlknght: I just downloaded a clean copy of jQuery Update 2.7 and I don't see ajax.js anywhere in it. I also can't find it anywhere in the git history of that project. Maybe there was some patch that you applied at one point that put it there?

I have the same problem on d6 (drupal 6).

Can anybody fix it for this?

@kazah - you might find that the D6LTS project release a backport at some point:

https://www.drupal.org/project/d6lts

If you're not already tracking the patches released by this project on a D6 site, can I suggest you do? There have been quite a few security updates for D6 released this way since it went EOL.

Chrome rolled out their fix already as well. So even if no one backports this for D6, just restarting Chrome should do the trick.

Thank you my friend!
I have restored my old version of the site ....spent three days for this awfull error))

Simply restart Chrome helped me. Thank you very much!

This bug seems to have landed in Microsoft Edge now.

This fix applies to Microsoft Edge as well.

Whereas #19 had fixed the issue for me, #83 does not fix the issue. I am still encountering the bug with "Add more" buttons on Drupal 7.71 in Chrome 83. So should this rightly be called fixed?

@earthday47 I'm not sure if that sounds like exactly the same issue.

Could you please file a new issue with as much detail as possible; ideally including steps to reproduce the issue with a clean copy of D7 and any modules necessary, plus exact browser versions etc..

It's on you to debug this, read through the issue, try out the patches and/or update your site.

This issue may help some of you with the Drupal core update 7.73 and entity reference autocomplete field https://www.drupal.org/project/jquery_update/issues/3171591