I think we should turn off the gatherExtendedBrowserInformation by default and give a hint that there is a synchronisation point of 0,011 ms when turned on, but the detection is much more reliable with the new implementation.
kind regards Tobias > Am 22.06.2018 um 11:49 schrieb Maxim Solodovnik <solomax...@gmail.com>: > > Is it time to resume this discussion? > We still have PR unmerged, and don't have agreement what to do next :( > > On Tue, Apr 10, 2018 at 3:08 AM Tobias Soloschenko < > tobiassolosche...@googlemail.com> wrote: > >> :-D >> >> kind regards >> >> Tobias >> >>> Am 09.04.2018 um 19:14 schrieb Sven Meier <s...@meiers.net>: >>> >>> bike shed :P >>> >>> Sven >>> >>> >>>> Am 09.04.2018 um 18:12 schrieb Maxim Solodovnik: >>>> This topic is more active than the release one :) >>>> >>>> On Thu, Apr 5, 2018 at 7:22 PM, Tobias Soloschenko >>>> <tobiassolosche...@googlemail.com> wrote: >>>>> -1 for dropping agent detection >>>>> +1 for adding a dependency to an external library (because of the big >> pool of browsers - which might increase in future) >>>>> >>>>> kind regards >>>>> >>>>> Tobias >>>>> >>>>>> Am 05.04.2018 um 13:44 schrieb Sven Meier <s...@meiers.net>: >>>>>> >>>>>> +0 for dropping agent detection (3) >>>>>> -1 for adding a dependency to an external library >>>>>> >>>>>> Sven >>>>>> >>>>>> Am 3. April 2018 16:34:15 MESZ schrieb Maxim Solodovnik < >> solomax...@gmail.com>: >>>>>>> It seems the discussion is spread between this thread and the JIRA >>>>>>> >> https://issues.apache.org/jira/browse/WICKET-6544?focusedCommentId=16423835&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16423835 >>>>>>> >>>>>>> As far as I can see we don't have consensus if this feature should >>>>>>> 1) remain as is (drop PR) >>>>>>> 2) be improved (merge PR and/or enhance detection) >>>>>>> 3) browser detection should be dropped? >>>>>>> >>>>>>> I would vote for option 2+ :) >>>>>>> >>>>>>> On Mon, Apr 2, 2018 at 5:11 AM, Martin Grigorov < >> mgrigo...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> On Thu, Mar 29, 2018 at 1:31 AM, Korbinian Bachl < >>>>>>>> korbinian.ba...@whiskyworld.de> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> ----- Ursprüngliche Mail ----- >>>>>>>>>>> even in 2009 it was considered bad: >>>>>>> https://www.sitepoint.com/why- >>>>>>>>>>> browser-sniffing-stinks/ >>>>>>>>>>> and in case that is not enough, read what the guy that invented >>>>>>>>> modernizr >>>>>>>>>>> has to say: >>>>>>>>>>> http://farukat.es/journal/2011/02/499-lest-we-forget-or- >>>>>>>>>>> how-i-learned-whats-so-bad-about-browser-sniffing/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I do not trust anyone who says "don't do it this way" but doesn't >>>>>>> say >>>>>>>> how >>>>>>>>>> to do it! >>>>>>>>>> >>>>>>>>>> There are several of "if (isBrowserX()) {...} else {...}" in >>>>>>> Wicket JS >>>>>>>>> code >>>>>>>>>> and they served well for the last decade. >>>>>>>>>> Since there are several other *Java* libraries for user agent >>>>>>> detection >>>>>>>>>> this means that someone still finds them useful despite what >>>>>>> other >>>>>>>> people >>>>>>>>>> claim. >>>>>>>>> unreliable things wont get reliably by pointing into the past and >>>>>>> then >>>>>>>>> telling that your fater did it the same way.... >>>>>>>>> >>>>>>>>> nowadays you would use feature detection, see: >>>>>>>>> >>>>>>>>> https://developer.mozilla.org/en-US/docs/Learn/Tools_and_ >>>>>>>>> testing/Cross_browser_testing/Feature_detection >>>>>>>> >>>>>>>> Korbinian, >>>>>>>> >>>>>>>> The PR by Maxim is about the User-Agent detection at the *server* >>>>>>> side, >>>>>>>> i.e. in the *Java* code. It reads the request header and tells you >>>>>>> what the >>>>>>>> browser is. >>>>>>>> The JS feature detection is only client side. You will need Ajax >>>>>>> behaviors >>>>>>>> to send the ourcome to the server to be able to use it there. Wicket >>>>>>> does >>>>>>>> this with (Web)ClientInfo related classes. >>>>>>>> >>>>>>>> I'll be VERY glad to see your PR that uses modern ways to redo the >>>>>>> current >>>>>>>> checks in wicket-ajax.js or in the server code, e.g. Wicket >> Bootstrap >>>>>>> uses >>>>>>>> this information to decide whether to render respond.js! >>>>>>>> Until then please do not make such bold statements. It is easy to >>>>>>> read an >>>>>>>> article and say "this is the [new] silver bullet". Until you get >> your >>>>>>> hands >>>>>>>> dirty you never know what kind of problems you will face! >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> btw: >>>>>>>>>>> https://github.com/HaraldWalker/user-agent-utils -> this is EOL, >>>>>>>> guess >>>>>>>>>>> why... >>>>>>>>>>> https://github.com/pieroxy/java-user-agent-detection/releases -> >>>>>>> last >>>>>>>>>>> release from september 2017... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Sep 2017 is like yesterday >>>>>>>>> (all only MAJOR releases!) >>>>>>>>> >>>>>>>>> 28. September 2017 - Firefox 56 >>>>>>>>> 14. November 2017 - Firefox 57 Quantum >>>>>>>>> 23. Januar 2018 - Firefox 58 >>>>>>>>> 13. März 2018 - Firefox 59 >>>>>>>>> >>>>>>>>> 2017-09-05 - Chrome 61.0.3163 >>>>>>>>> 2017-10-17 - Chrome 62.0.3202 >>>>>>>>> 2017-12-05 - Chrome 63.0.3239 >>>>>>>>> 2018-01-23 - Chrome 64.0.3282 >>>>>>>>> 2018-03-06 - Chrome 65.0.3325 >>>>>>>>> >>>>>>>>> and this is just 2 desktop ones! I dont want to talk about the >>>>>>> loads of >>>>>>>>> updates my android device got in that time (firefox mobile, chrome >>>>>>> and >>>>>>>>> samsung internet!) - oh, and btw: they still lie about the user >>>>>>> agent all >>>>>>>>> time.... dont get me wrong, but sep 17 is freaking old in case you >>>>>>> need >>>>>>>> to >>>>>>>>> reliably detect the browser! >>>>>>>>> >>>>>>>> Yes, and all of them are properly parsed by the same code that has >>>>>>> been >>>>>>>> used in the last decade! >>>>>>>> The browser vendors have no reason to change their syntax of user >>>>>>> agent. >>>>>>>> Believe me they do know that this piece of information *is being* >>>>>>> used in >>>>>>>> the wild! >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> WBR >>>>>>> Maxim aka solomax >>>> >>>> >>> >> > > > -- > WBR > Maxim aka solomax
