Config option to disable global search

[kalenjordan]

Hey Alan!

Thanks for the sweet module! I made a quick modification to allow for the global search to be disabled (enabled by default), because I found that at least in my local environment, it was taking ~10 seconds to navigate to a config page instead of ~2 because of the time it needed to do the global search, and I likely won't be using that too much - although I think the feature is really sweet. Would be amazing if we could find a way to speed it up b/c I'd love to get support staff and such to be able to use it to quickly navigate to orders and customers.

At any rate, this is probably a dumb question, but I actually am using Fabrizio's fork that just contains the Launcher module - you probably would want the pull request submitted against this repo I'd imagine?

Btw I also submitted a pull request to his module to update it from version 0.1.1 to 1.0.3, pulling from your latest.

[astorm]

I'm assuming this is for the Pulse Storm launcher?

I'm not sure I understand the following.

it was taking ~10 seconds to navigate to a config page instead of ~2 because of the time it needed to do the global search

Where's the 10 second delay coming from?

[kalenjordan]

I was kind of confused by it myself. It seemed that it was because of the global search AJAX call. The particular store I was testing with has ~30k customers and ~50k orders, not sure if that's a factor or not.

I wouldn't have thought that the AJAX call would block the subsequent page load, but that's what it seemed to be doing. Removing the global search sped that page load right up.

[astorm]

I just tested this a with a long sleep() call in the globalSearchAction method and I was able to reproduce the problem.

I'd rather get to the bottom of this than add an option to disable global search (especially since you can also disable global search via ACL) My guess is there's some callbacks in the XHR implementation that need to be call before a new page can be loaded, and they can't be called until the request finishes. (waves hands, mutters abou gremlins)

Maybe if we try aborting the ajax request when a link is clicked on, and also when the javascript function go_to_highlighted_link function is called.

I'll try looking into this later this week, but if you wanted to tackle the above I'd happily accept a pull request.

[astorm]

One last note fro today — the delay only seems to happen when you're trying to go to an internal link. That is, if I replace the document.location= with

document.location = 'http://google.com';

it redirects instantly. So, I think what's happening is the global search is queuing up multiple ajax requests, and reaches the browsers "per domain" limit. So even though we're aborting the older requests, for some reason the browser still wants to finish them. This will probably require a minor/intermedia refactor of the global search ajax code.

[kalenjordan]

Ya you're totally right, would be better to get this root cause fixed. If I can find some time tomorrow, I'll look into maybe aborting the ajax request, that sounds promising.

[astorm]

I poked at this a bit today — it seems to be more complicated than an AJAX thing. Try

1. Perform a long polling search in the global search field
2. While that search is going on, run document.location = 'http://magento1point7pointzeropoint1.dev/index.php/admin/dashboard' from Chrome's javascript console

With the above I see the same unexpected behavior: Chrome waits until the ajax request has finished before allowing the document.location call to finish. Are there any known bugs for the backend console locking things to a single request?

[astorm]

Kalen — I think I tracked this down to a session locking issue. I just pushed a change that should take care of things. Give it a try and let me know if it works with your large data set.

[kalenjordan]

Awesome! Much better! It's down from ~10s to ~3.25s and I can see the pulser going away once I select an option to navigate to. It does still seem to reliably be ~0.75s slower than a regular page load into this particular section of my config, but that's definitely manageable.