There's a lot of options here. Joomla\Application\Web\WebClient is honestly worse than JBrowser. I'm unconvinced that many (if any) people use JBrowser parts of JHtml so honestly it comes down to the mobile detection, which is used more.

Do you think it would be worth replacing Joomla\Application\Web\WebClient with JBrowser?
note: It would make a bit of a mess in the framework since the two classes have different return values.

Looking at the current state of Joomla\Application\Web\WebClient I don't think deprecating JBrowser is a very good idea. You have to use some black magic like PHP to "stringify" the return values of WebClient which are integers only, where JBrowser returns some very convenient values like "unix", "mac", "chrome", "mozilla" etc.

You have to use some black magic like PHP to "stringify" the return values of WebClient which are integers only

It's not an issue unique to this class. Anything which uses constants to represent values can have this issue where the constant's value doesn't necessarily align to what the code is passing. WebClient::MAC will always be integer 7 (or if we took the B/C break and changed them to strings whatever string value it's assigned), but you can use the constant to read the value versus hardcoding a 7 into your code and having to leave inline comments about what it actually represents.

It's not an issue unique to this class. Anything which uses constants to represent values can have this issue where the constant's value doesn't necessarily align to what the code is passing.

I do understand that it might be better to prefer constants in terms of performance, I just wanted to point out that currently there seems to be missing a method for extension-developer friendly output. Deprecating JBrowser in favor of the current verison of WebClient would easily result in developers repeating themselves (instead of DRY in the core) or even worse: using third party libraries.

Another thing: if you add some functionality e.g. in detection of browsers this might result in problems even if there are hardcoded values always staying the same (until one day they won't :) ).
Lets say an update is adding constant 42 as return value for a fork of a browser. This would force every extension/template developer to review or rework their code.
Of course you could do something like: array_shift( (new ReflectionClass( 'JApplicationWebClient' ) ) ->getConstants() ); but I guess this would not perform very well.

Lets say an update is adding constant 42 as return value for a fork of a browser. This would force every extension/template developer to review or rework their code.

And it'd be the same if a new return value were added into JBrowser which uses "developer friendly" strings if your code was interested in a behavior for that browser. So I don't think that scenario strengthens or weakens the case for constants versus string values that aren't declared somewhere (as in right now you basically have to reverse engineer JBrowser to know what you can get from it, at least with a list of constants you have a set of known values).

as in right now you basically have to reverse engineer JBrowser to know what you can get from it, at least with a list of constants you have a set of known values

I totally agree with you. I was never saying JBrowser was a better class, but it's easier to handle since it provides human-readable results. I'd be totally satisfied if there was a built in ability to resolve the name of the constants in WebClient and I guess others would be too.

In my case I'm just logging values like browser, version and OS which is hard to read if you get constants only.

Honestly, I don't know if that's something that's practical in PHP since constants are just a code shortcut to a value (everything internally uses that constant's value, the constant's just there for readability). You can use Reflection and come up with methods to help make that work on a class basis, but global constants would never work that well with a resolver since many share the same value.

At this point, I'd suggest whichever of the two classes is in better shape is the one we should move forward with and the other one deprecated and dropped with next major. Internal design decisions aside (i.e. constant values), I'd rather focus on whichever one is more functionally up to par for the task at hand and we can address the shortcomings in that class and if necessary correct design issues.

Anyone?

I mean JBrowser covers more cases. The question is does WebClient cover the common cases - because most people care about desktop vs mobile etc. Not what the specific browser is....

I think they both cover the same small set of browsers (at least from what I remember from the minor code fixes I've done to both of them)

both cover desktop vs mobile

• JBrowser
• The framework webclient

Here is a quick properties comparison between the two (I think I got everything in here)
Still need to do a function comparison to get the full picture

Here is a quick function comparison between the two (I think I got everything in here)
As best I can tell there is feature parody between the two, a few functions here and there are not in the other class. but the big things like mobile detection are in both.

Sorry, I fat fingered the keyboard. I didn't intend to close this, thus it's been reopened.

Status changed from "New" to "Discussion".

Thank you for raising this issue.

Joomla 3 is now in security only mode with no further bug fixes or new features. It appears that this has already been addressed in Joomla 4 and it will now been closed.

If we are mistaken and this does apply to Joomla 4 please open a new issue (and reference this one if you wish) with updated details for testing in Joomla 4.
cc @zero-24