Improve browser detection (BZ#2274)

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

At the moment is isn't possible to know which browser is running. We only know the JavaScript engine, but this is in some use cases not enough. e.g. Safari and Chrome, both use the webkit engine, so it isn't possible to infer form the webkit engine to the running browser. A new implementation like a "qx.bom.client.Browser" class, which contains the browser name and version could be helpful.

To implement a "qx.bom.client.Browser" is only a suggestion. Other ideas are welcome.

assigned to Christian Hagendorn (@Hagendorn)

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

An uncompleted browser list that could be important for the implementation: Google Chrome Safari Internet Explorer Maxthon (major IE alternative in China) Firefox Flock (Social Firefox alternative) Opera Opera mini/mobile

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

* BZ#1783 has been marked as a duplicate of this bug. *

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

* BZ#2153 has been marked as a duplicate of this bug. *

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Opera mini/mobile are in fact two browsers.

Netfront is a huge browser for mobiles in Asia.

I would also add:

• Konqueror (what's the state about konq at all?)
• Epiphany (uses webkit)
• Camino (Mac Firefox alternative, uses gecko)

Important would be IMHO to have the browser detection in the specific variants of the clients to not include Camino detection in an MSHTML build for example.

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

to Daniel. Please come up with a concept/proposal first.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

I have a set of improved Feature/Engine/Client/Browser detection classes here which I could contribute.

But they break the compatibility with the current implementation (at least if one uses the same class names)

[qx-bug-importer]

Daniel Wagner (@danielwagner) wrote:

Sounds interesting, could you please attach the diffs to this bug report so we can review them?

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

I will do this as soon as I have them a little bit more complete for our needs. I will put me a reminder in my calendar for next week. Hope this is OK for you.

[qx-bug-importer]

Daniel Wagner (@danielwagner) wrote:

Sure, that's fine. Looking forward to seeing the code.

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

Sebastian, updates on this one?

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

I will attach what I have at the moment...

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

I need a few further tweaks. I will do the other stuff tomorrow. Sorry for the delay.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

I still need some time to figure out some things. Would it be ok to commit the stuff to qx.bom.client2 so you can see my progress and give comments?

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Alex, Christian, any news here?

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

See also #1995

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

Sebastian, would be great to get your current implementation into "the pipeline" for review/discussion.

Working towards 1.0, of course, the # of "*2" namespaces should decrease not increase , so I suggest attaching a patch here or creating a qooxdoo-contrib. The latter should be pretty straightforward, and it might be the best incubation for some larger (but self-contained) additions/alternatives (also depending on the size/impact of your code). When using identical class names, a robocopying script could be handy, what'ya think? Please note that Daniel isn't here this week.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

If there is currently no interest in bringing these things in, I keep them where they are in our project as it makes it easier for now to updating it and supporting new platforms.

The only issue I have with this approach is the size penalty added through a double implementation of the client detection.

When I look into my code the only really problematic class is Engine.js which is basically crap in qooxdoo (yeah yeah - it was part of my original work) ;)

Other classes are basically additions which should be easily doable or splits (into separate files) which might be solvable with migration. As I said the main issue in Engine.js.

What's about adding a "client2" namespace for the moment with the new layout where I put all these files together with the original files. That might help to get an image of the changes. IMHO better than dealing with patch files in this case.

What do you think?

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

Sure there's much interest in your contribution, that's what I said. Christian is about to look into an improved client detection himself, so it would be best to get your code into the pipeline to not end up with some redundant or even conflicting solutions.

It would be best you attached the code as a patch (or even a client2 zip) as suggested. This should be a minimum of effort on your side, and would allow Christian to take that into account easily. That way there'll be no need for a temporary "client2" namespace, and we hopefully have an improved detection in trunk soon.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

What I can offer easily is a ZIP of our currently onmodified files with the wrong namespace: unify.bom.client.*

This would me allow to easily add new features from our trunk as soon as they are ready. Our code already depend on these classes and they have some tweaks from week to week.

As I am already away from my company workplace I would attach the files tomorrow. Let's see how far we get with the implementation.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Re-implementation of client-detection

Goals:

• Browser Detection
• Mobile Platform Detection
• Device Category Detection
• Modularity (Split Version/Engine Detection)
• Split Feature & Extension Detection

ERROR: no way found to migrate client.zip (application/zip) from bugzilla.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

BTW: The patch I submitted in comment #20 is licensed under LGPL/EPL and this way might be used in qooxdoo.

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

To me.

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

Accepted.

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

Sebastian, thanks for sharing your code. I talked with Fabian and we will use your Browser and Version code, this would solve our browser detection issue.

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

Sebastian, I committed your Browser and Version class on trunk with rev. 20733. Could you please have a look on it, especially on the header? Thanks.

[qx-bug-importer]

Christian Hagendorn (@Hagendorn) wrote:

I opened a separate BZ#3097 for the improvements on qx.bom.client.* and set the bug to fixed. Sebastian, please reopen the bug if something is wrong with my commit rev. 20733.

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Christian: Great you have integrated both of them. Still I would love to have a migration plan for the other things as well. The headers looks OK!

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

Just using Version.js without Engine.js produces some kind of overhead as both classes have some kind of engine detection. Regarding your idea of a as-clean-as-possible 1.0 release this addition makes not a lot of sense.

May I suggest to have a slightley modified Engine.js (from my contrib) to be compatible with the previous version and add migration data to have the version stuff moved to qx.bom.client.Version?

[qx-bug-importer]

Sebastian Werner (@swernerx) wrote:

What's about this:

• Renaming qx.bom.client.Engine to qx.bom.client.Client (which reflects the variants name)
• Add qx.bom.client.Engine from my contribution
• Add a variant "qx.engine" which uses the value of the new Engine class (trident, gecko, presto, webkit)
• Use "qx.engine" in qooxdoo whereever previously "qx.client" has been used.

[qx-bug-importer]

Andreas Ecker (@ecker) wrote:

mass renaming of 0.9 target to 1.0-beta1

[qx-bug-importer]

Martin Wittemann (@wittemann) wrote:

Closed all bugs already shipped with a release.