Well, I put the sniff in my blog<http://webreflection.blogspot.com/2009/01/32-bytes-to-know-if-your-browser-is-ie.html> . IE always throws an illegal assignment, other browsers do not generate any exception and as long as constants reassignment wont generate exceptions this trick seems to be library/hack prone. If it fails, please tell me so I can update my blog entry.
Cheers On Wed, Jan 28, 2009 at 8:28 AM, Andrea Giammarchi < [email protected]> wrote: > Was it that bad? :D > > > On Tue, Jan 27, 2009 at 10:45 PM, Andrea Giammarchi < > [email protected]> wrote: > >> alert, setInterval and setTimeout via silly tricks can be reassigned. >> Apparently, IE does not allow the reassignment of the window.window, at >> least static in other browsers. >> >> try{window.window=null}catch(e){$.isIE=true}; >> >> >> >> >> >> >> On Tue, Jan 27, 2009 at 9:46 PM, Diego Perini <[email protected]>wrote: >> >>> >>> Juriy, >>> we agreed that if we can write something in the DOM everybody else can >>> delete/overwrite it and fold our testing. >>> >>> Your feature test on the "alert()" method will probably have failed >>> with this old piece of code of mine :-) >>> >>> http://javascript.nwbox.com/asyncAlert/ >>> >>> >>> Diego >>> >>> >>> On 27 Gen, 22:20, kangax <[email protected]> wrote: >>> > On Jan 27, 1:37 pm, Diego Perini <[email protected]> wrote: >>> > [...] >>> > >>> > > One "span" element with an id="length" will do much more damages to >>> > > every existing framework/library, and there are tons of properties >>> > > that can be overwritten. Should we also hope no other browser >>> > > implements conditional comments ? >>> > >>> > > Are you interested in how much a test is "foldable" or how good it is >>> > > into recognize if the browser is IE ? >>> > >>> > > First case you win, second case I win. >>> > >>> > I'm not sure I understand your argument. Second "case" actually >>> > somewhat depends on the former one - how "good" it is would surely >>> > depend on how hard it is to *accidentally* break it. I also have no >>> > idea why you would want go with the weaker test when other - more >>> > robust ways - are available. Is it because `fileSize` saves few lines >>> > of code? It's up to you of course, but if something is known to >>> > produce false positives (in a not so contrived case scenario), why not >>> > try alternative approach? Chances of `document.fileSize` being truthy >>> > are too big (as for my taste); Its value is easily changeable by any >>> > 3rd party script. Why such risk? Why not use test that operates on a >>> > lower level? >>> > >>> > I would probably try testing for behavior that can not be easily >>> > overwritten. Something that is at the core of the object/host model. >>> > Something like: >>> > >>> > var IS_MSHTML_DOM = (function() { >>> > var global = this; >>> > return ( >>> > global.alert && >>> > // some host methods return "object" for `typeof` >>> > typeof global.alert == 'object' && >>> > // some host methods do not inherit from `Function.prototype` >>> > typeof global.alert.call == 'undefined' && >>> > // some host methods throw errors on setters >>> > (function(){ >>> > try { >>> > global.alert.x = true; >>> > return false; >>> > } catch(e) { >>> > return true; >>> > } >>> > })() >>> > ) >>> > >>> > })(); >>> > >>> > While it's still possible to fool this test, chances of that are, imo, >>> > much lower. >>> > >>> > -- >>> > kangax >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
