jQuery upgrades for Infusion (FLUID-5185)

[Colin Clark]

Hi Antranig,

Yes, I agree that the removal of jQuery.browser is a case where principle has been completely divorced from pragmatics. While I understand that, in principle, user agent detection is brittle, unresponsive to changes in browser implementations, and should generally be avoided, in practice it is a tool that we sometimes need to resort to when we’ve got browser or version-specific bugs to work around. It’s often very difficult to feature-detect a bizarre bug in a particular version of IE, for example.

I’ve been using jQuery 2.0 and the current head of the Infusion framework with Flocking since May. The only major issue I encountered when upgrading to jQuery 2.0 was the removal of jQuery.browser. Even in a codebase that doesn’t support IE at all, I found that I sometimes need to resort to user agent detection to work around browser-specific latency and performance issues. There’s just no way to avoid it. You can’t feature detect the poor performance of the audio subsystem in Firefox on Linux, for example.

In the end, I resorted to reintroducing jQuery.browser from jQuery 1.8 into Flocking’s core file. I did some hack-and-slash to make it work reasonably for my particular purpose:

https://github.com/colinbdclark/Flocking/blob/master/flocking/flocking-core.js#L48-L85

If we do the same for Infusion, I will happily be able to remove this from Flocking.

So, to summarize, I think it makes sense to:

1. Review each instance of jQuery.browser usage and see if we can remove it as part of dropping legacy browser support in 1.5
2. Fork the implementation of jQuery.browser from jQuery 1.8 and include it as part of FluidView.js as “fluid.browser”

Colin

On Dec 18, 2013, at 3:03 AM, Antranig Basman <Antranig.Basman at colorado.edu> wrote:

> As expected, a major issue upgrading our core jQuery dependency from its more than year-old status at 1.7.2 has been the elimination of the jQuery browser detection utility, $.browser. This is used throughout the framework and several components, and despite the "popular religion" to the effect that such detections should not be used, I think we have enough browser-specific bugs that we require to compensate for that this is not feasible in the "real world". Certainly we should commit to a review process to vet each of our couple of dozen usages of $.browser(), since many of the bugs that they work around may have been long fixed, or appear in browsers outside our support profile - however, this process would unnecessarily slow down the release process of Infusion 1.5 and so I believe we must work to restore the $.browser implementation.
> 
> Unfortunately the recommended workaround by the jQuery team, the use of the "jQuery Migrate" plugin seems to me quite undesirable. For a start, it means taking into the delivered framework image a large amount of code (c. 500 lines) most of which we have no use for - since the framework's use of jQuery is generally conservative and the whole purpose of this upgrade is to bring it up to date with the latest API - the use of a module whose overall purpose is to adapt to obsolete versions of the jQuery API seems perverse. Into the bargain, the grip of the "popular religion" on the minds of the jQuery developers lead them to implement this library in a noisy way which produces console warnings on any use, and in particular use of the $.browser detect which is our only reason for using it.
> 
> This warning takes the form of the message "JQMIGRATE: jQuery.browser is deprecated" preceded by a exclamation icon and followed by a complete stack trace. This is unreasonably intrusive. In addition, adopting this plugin would require an edit to every single HTML demo and test file in the framework image to add in the new dependency.
> 
> My suggestion for resolving this is to "rip off" an implementation of the small portion of the code that we actually require (about 10 lines) into a polyfill in our existing framework file FluidView.js. Another possibility is FluidDocument.js, but this latter file contains rarities that are less often included in framework tests and demos. Naturally neither choice makes a difference to users of built copies of Infusion since both are always included by default.
> 
> Please reply with opinions, feedback and alternatives to this proposal -
> 
> Cheers,
> A
> _______________________________________________________
> fluid-work mailing list - fluid-work at fluidproject.org
> To unsubscribe, change settings or access archives,
> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work