Re: Problems with BrowserVersion - Feedback required

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Re: Problems with BrowserVersion - Feedback required

Seems fine to me. We use customized new BrowserVersions instead of
setters to change the default BrowserVersions if we want to change some
browser properties.

在 2017/6/17 3:15, Ronald Brill 写道:

> 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 =;
>    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
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites,!
> _______________________________________________
> Htmlunit-user mailing list
> [hidden email]

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Htmlunit-user mailing list
[hidden email]