tighten selector scope for blur trigger

[scottjehl]

discussion here. Assigning to me.
823485c

[jblas]

So the proposed fix from the comments in the patch mentioned above (for #1840) is:

$( "." + $.mobile.activePageClass + " .ui-btn:focus" ).not( $( link ).closest( ".ui-btn" ) ).blur();

In my testing of the original patch:

$( "." + $.mobile.activePageClass + " .ui-btn" ).not( link ).blur();

I'm still not seeing any difference, with/without the fix on iOS (iPod 2nd Gen 4.1, iPad 1st Gen 4.2.3). I was still seeing the hover states when going back to the first page. I debugged a little, and this is what I see going on, at least with the code in the HEAD as of 11am today:

The hover color is being placed on the previously clicked link due to the reFocus() function in the navigation code. When we re-visit a page, we restore the last focused element for that page. This is triggering the "vmouseover focus" event handler in the buttonMarkup code that places the hover class on the element. So if we want to get rid of this behavior, we'll need to split the handler so that it only places the class on vmouseover instead of focus.

The 2nd issue I see is that the blur handlers for the buttons aren't firing due to the fact that the ajax handling is now done on "vclick click" for iOS. This is probably due to the fact that we are preventing default on the touch events which impacts the mouse events ... and focus/blur happen in conjunction with mouse events. I noticed that as I click links, the previously lit (hovered) link doesn't get its hover class removed. If shut off the "fastClick" use of "vclick click" so that we go back to using "click" things work better. As soon as I click on a new link, the previously lit one goes out prior to the page transitioning.

One other curious thing I noticed. We seem to be attempting to blur() out the document.activeElement and some form inputs in changePage(). Is document.activeElement supposed to change depending on what the user last focused? I ask because it seems to always be body.

[justKeith]

I was wondering if this had been given anymore thought. I started out looking into extremely poor performance in IE 8 and ended up on this same line. On a screen with a large listview such as the list performance test in the docs even clicking on the home button can take 30+ seconds on a fast machine. Even on much smaller lists (~30) you still get unacceptably long pauses when you click on any link.

I went a little bit of a different way but it resulted in a order of magnitude reduction in the hang time in my application. The performance is still an embarrassment next to any other browser but at least it's usable. I haven't been able to compare the performance between what you have above and what I did but I will tomorrow. I also haven't checked a lot mobile devices yet.

justKeith@dd8e668#diff-0

[jaspermdegroot]

@justKeith - There are now two tickets for this issue. I am closing this one. Thread goes on here... #4340
If you find your changes indeed improve performance please share your suggestion there. Thanks!