From: Ronald B. <rb...@rb...> - 2017-06-16 19:15:45
|
Hi HtmlUnit users, hi HtmlUnit developers, it looks like we have currently a major design flaw with the way HtmlUnit handles different browser versions. The problem is in short: * the final browser setup is done by different technics; getter/setter in class BrowserVersion, Jsx annotations and constants in BrowserVersionFeatures * the user is able to define (clone) browser versions but in the end only limited parts of the setup is realy changeable; this has lead to some wrong expectations and misunderstanding in the past * the browser version is used inside the code without taking care of this cloned versions and this might be the root of some errors we got * it is possible to change parts of the BrowserVersion at a later point, the code is not aware of this and does strange things Because i think we are not able to fix this in a backward compatible manner i like to discuss possible solutions here. Suggestions: * it will still be possible for the user to create browser versions based on the existing ones * the user can only configure the part of the browser setup that is configurable at the moment by using the setters in BrowserVersion * to avoid problems and later changes of the BrowserVersion we will support this by using a builder pattern similar to this BrowserVersionBuilder builder = new BrowserVersionBuilder(BrowserVersion.CROME); builder.setPlatform("BeOS"); .... BrowserVersion myBeBrowser = builder.build(); new WebClient(myBeBrowser); ** if there is an BrowserVersion with exact the same setup as your Builder is asking for, this will return the already existing BrowserVersion ** using the BrowserVersionBuilder you will have similar options as you have today for the BrowserVersion ** it is no longer possible to change the BrowserVersion itself because the setters are longer available This will have some imlications for you current code: * HtmlUnit will internally maintain a list of browsers - mabe you can get a browser from this list by name * BrowserVersion will be fixed if you finished with the setup, it will not be possible to change the configuration later on (this is possible today but will definitly introduce trouble for you) * you have to adapt your code * It seems to be possible to introduce this change the usual way by making the existing API deprecated and remove with later versions What do you think. Is this ok for our brave users? Do you need support for more? Any better ideas/suggestions/improvements? RBRi -------------------------- WETATOR Smart web application testing http://www.wetator.org |