When checking the DNM (Do Not Migrate) box for destination fields I do not want populated by migration, I get the following notice in Firefox:

Unresponsive script

A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: http://localhost/misc/jquery.js?v=1.4.4:84

It appears every time I try to select a box.

CommentFileSizeAuthor
#10 migrate-remove-ajax-1999228-9.patch2.65 KBmikeryan
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mikeryan’s picture

Project: Drupal-to-Drupal data migration » Migrate
Component: D7-specific » migrate_ui
Status: Active » Postponed (maintainer needs more info)

The field mapping page is migrate_ui, not migrate_d2d.

Clicking the DNM box requires updating the page, so some AJAXy stuff happens, and the more stuff in the form the longer this will take. How many destination fields do you have in that migration? How many source fields? How long do you have the "Please wait" before Firefox complains?

pixelsweatshop’s picture

Status: Postponed (maintainer needs more info) » Active

Destination Fields: 64 (Most of the destination fields are from the metatags module and nothing is being migrated to these)
Source Fields: 22
"Please Wait" time: 10 seconds

mikeryan’s picture

Component: migrate_ui » Performance

How long does it take to initially load the mappings edit page? The AJAX update shouldn't take any longer than that.

We'll have to look and see if there's some way to improve the performance of the page, it may be a challenge...

pixelsweatshop’s picture

How long does it take to initially load the mappings edit page?

It loads immediately.

I can confirm that if there are less fields to map (around 20) it works without issues.

mikeryan’s picture

As it happens, one of my current projects has a migration using metatags and thus also has tons of fields - I have not had the "Unresponsive script" message (I am also using Firefox), although it does take a long time for things to update. It takes a much longer time to update on click than the initial loading of the form, even though the exact same Migrate code is executed, which suggests to me that the AJAX is the slow part - I'm not sure how much we can do about that. I'd guess maybe your machine is slower than my Macbook Pro, enough that the Javascript takes too long.

For now, what may work is to edit your Firefox configuration to allow scripts to run longer - in the search bar type "about:config", accept the great responsibility, and edit the dom.max_script_run_time value to a larger value. If you do this and it works, I'd like to know how long the "Please wait" time lasts.

Thanks.

mikeryan’s picture

Just a note - I was able to reproduce the issue by setting my dom.max_script_run_time to 10. Not sure I can do much about the Javascript side, but maybe I can find some time savings in the form code.

pixelsweatshop’s picture

Firefox defaults the dom.max_script_run_time to 10. I upped it 20 and it still failed. It eventually worked once I moved it up to 30.

I'd like to know how long the "Please wait" time lasts.

After upping it to 30, the wait time was clocked at 24.

I tested in the latest chrome, safari opera (all default settings) and they worked without issue. Wait time was closer to 10-15.

mikeryan’s picture

Mixologic’s picture

As I had mentioned on the other issue, a quick heap profile shows that the vast majority of the javascript processing time is eaten up by the drupal #states api. If you have a lot of form fields on a page, the #states api is a hog, and will scuttle any hope of performance.

As a workaround, I commented out all of the #states declarations on the three form elements in migrate_ui.pages.inc (lines 1132-1170). This makes the form usable, though you'll still need to make sure you don't have anything entered in those fields.

A more permanent solution is to forgo using the drupal #states api and add a jquery click handler to the DNM checkboxes (oddly named 'issue_group' on the form) to directly disable the mapping, default_value, and source_migration form fields.

The most permanent solution would be to file a core bug and see if there isn't a better way to solving the #states architecture on very large forms. Its basically an O(N2) algorithm - in other words, we're probably not the only ones who suffer from this issue. Im sure if we hunted around on D.O. for 'unresponsive script' we'd find a lot of instances where #states was the culprit.

mikeryan’s picture

Status: Active » Needs review
FileSize
2.65 KB

Given that I'd like to (finally) release 2.6 in the near future, and I don't have the JS chops to implement an alternative to #states, I think the best option (unless someone in the community can contribute an alternative) is to simply remove dynamic updates to the form. Patch attached.

roberttstephens’s picture

migrate-remove-ajax-1999228-9.patch fixes the javascript timeout issues that I was seeing.

mikeryan’s picture

Status: Needs review » Fixed

Committed the patch in #10.

  • Commit e0a9309 on 7.x-2.x by mikeryan:
    Issue #1999228 by mikeryan: Removed AJAX from field mapping form for...
mikeryan’s picture

Issue tags: +Migrate 2.6

Tagging as 2.6.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.