Officially deprecating Opera permutation

[Goktug Gokdogan]

It looks like Opera 12's market share (the last non-webkit Opera version) is now below 0.5% and newer versions already should use the webkit permutation. The support was already very weak and we don't see any reason to continue it.

Similar to IE6/7 deprecation, we will start with disabling the permutation by default for 2.6 release and then start removing the code after that.

Let me know if you have any concerns.

[Colin Alworth]

Just to confirm, the plan is to set this in master as well as releases/2.6, and this will go out in 2.6.0-rc2?

[Goktug Gokdogan]

Yes, that's correct.

On Wed, Nov 20, 2013 at 12:08 PM, Colin Alworth <nilo...@gmail.com> wrote:

Just to confirm, the plan is to set this in master as well as releases/2.6, and this will go out in 2.6.0-rc2?

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jens]

Yes, that's correct.

Should be fine. 

[Thomas Broyer]

I don't.

Just note that on Linux, the latest version of Opera is still 12, Presto-based; there's no Chromium-based Opera (yet) on Linux. 

[Goktug Gokdogan]

Yes, I guess that accounts for 0.5% :)

--

[Robert J. Carr]

This just burned me.  Just curious why you couldn't have it load the file from firefox or webkit instead of just doing nothing?  Better to deal with potential errors than to be a total non-starter.

[Thomas Broyer]

Opera on Linux is basically dead.

There's not been a non-security-only or non-crash-fix-only release for 18 months (http://www.opera.com/docs/changelogs/unified/1210/)

Opera has moved to Chromium for more than a year and still not released anything on Linux. Either they waited for the Aura port (first appearance in the latest Opera release, so maybe there'll be a Linux release soon, at last) or they just don't care.

That said, Google Groups and Google Flight Search fallback to the gecko1_8 permutation in Opera 12 (with a warning message that it might break), so we should probably make it possible at least (Google uses a server-side selection script based on the User-Agent request header, rather than the *.nocache.js using navigator.userAgent on the client-side)

Would you mind opening an issue about it?

Maybe there's a workaround though: it might be as easy as defining a "unknown" (the value returned by the property generator) value for the "user.agent" property that falls back to gecko1_8 (just like ie9 falls back to ie8): i.e. <extend-property name="user.agent" values="unknown" fallback-value="gecko1_8" />; and then you could use deferred-binding specifically for that "unknown" value to display a warning message, and you could collapse "unknown" and "gecko1_8" values into the same permutation.

Worth a try IMO if you care about it.

[Mihai Stanciu]

"Google uses a server-side selection script based on the User-Agent request header, rather than the *.nocache.js using navigator.userAgent on the client-side)"

This sounds like a very nice optimisation. Do you know if there is any plugin for doing this in a servlet container /jsp?

How could find/generate  the mapping for "user.agent" -> permutation

Sorry for being offtopic.

[Jens]

"Google uses a server-side selection script based on the User-Agent request header, rather than the *.nocache.js using navigator.userAgent on the client-side)"

This sounds like a very nice optimisation. Do you know if there is any plugin for doing this in a servlet container /jsp?

How could find/generate  the mapping for "user.agent" -> permutation

A custom GWT linker can probably do that. But keep in mind that you only gain some optimization if your app only uses deferred binding properties that are based on the browsers user agent string. Deferred binding properties that need information not available on the server (e.g. screen resolution) won't work unless you collapse them into a single permutation so that this permutation can then be detected again on the server. This might cost more than you gain.

-- J.

[Colin Alworth]

I've just opened https://gwt-review.googlesource.com/7780 to make it possible to specify a fallback for any/all useragents that don't match one of the built-in rules, via a rule like:

    <set-property-fallback name="user.agent" value="webkit"/>

This example rule treats any unknown useragent as if it were webkit, rather than the non-existent 'unknown' useragent, which subsequently tries to load undefined.cache.html, etc. This could also be used in conjunction with defining a user.agent value for unknown browsers and falling back to an existing one (like Thomas suggested), along with a possible error message, but that runs the risk of failing to match any CssResource @if rules, for example. This will of course create a huge amount of warnings in your application "Could not find an exact match rule. Using 'closest' rule..." when attempt to rebind things that cannot be matched to unknown and fall back to gecko1_8, etc.

    <!-- Create new value, try and use ff details for it (most of the time) -->

    <extend-property name="user.agent" values="unknown" fallback-value="gecko1_8" />

    <!-- this line is not actually necessary unless you want to use a string other than 'unknown', and won't work before the above patch -->
    <set-property-fallback name="user.agent" value="unknown"/>
    <!-- 'most of the time' we want ff, except for a warning when the page boots. -->
    <!-- To achieve that, we create a second entrypoint that extends the real one, but also displays a warning about this browser being unsupported -->
    <replace-with class="pack.age.to.client.UnknownBrowserEntryPoint">
        <when-type-is class="pack.age.to.client.RealAppEntryPoint" />
    </replace-with>
   
Thomas, were you suggesting a filter in GWT itself to let the server do this, or to have an 'UnknownUserAgentEntryPoint' built into GWT itself?

On Saturday, May 10, 2014 5:27:37 PM UTC-5, Thomas Broyer wrote
...snip...

[Colin Alworth]

Sorry, that first line should say 'safari' (or any other valid user.agent value), not 'webkit'. Wishful thinking perhaps...

<set-property-fallback name="user.agent" value="safari"/>

[Thomas Broyer]

On Wednesday, June 4, 2014 5:43:58 AM UTC+2, Colin Alworth wrote:

I've just opened https://gwt-review.googlesource.com/7780 to make it possible to specify a fallback for any/all useragents that don't match one of the built-in rules, via a rule like:

    <set-property-fallback name="user.agent" value="webkit"/>

This example rule treats any unknown useragent as if it were webkit, rather than the non-existent 'unknown' useragent, which subsequently tries to load undefined.cache.html, etc. This could also be used in conjunction with defining a user.agent value for unknown browsers and falling back to an existing one (like Thomas suggested), along with a possible error message, but that runs the risk of failing to match any CssResource @if rules, for example. This will of course create a huge amount of warnings in your application "Could not find an exact match rule. Using 'closest' rule..." when attempt to rebind things that cannot be matched to unknown and fall back to gecko1_8, etc.

    <!-- Create new value, try and use ff details for it (most of the time) -->
    <extend-property name="user.agent" values="unknown" fallback-value="gecko1_8" />
    <!-- this line is not actually necessary unless you want to use a string other than 'unknown', and won't work before the above patch -->
    <set-property-fallback name="user.agent" value="unknown"/>
    <!-- 'most of the time' we want ff, except for a warning when the page boots. -->
    <!-- To achieve that, we create a second entrypoint that extends the real one, but also displays a warning about this browser being unsupported -->
    <replace-with class="pack.age.to.client.UnknownBrowserEntryPoint">
        <when-type-is class="pack.age.to.client.RealAppEntryPoint" />
    </replace-with>
   
Thomas, were you suggesting a filter in GWT itself to let the server do this, or to have an 'UnknownUserAgentEntryPoint' built into GWT itself?

I don't remember, but I don't think so.

From the review, I think having UserAgent#getRuntimeValue() returning 'unknown' in the fallback case would be enough:

class FallbackEntrypoint extends MainEntrypoint {

  @Override

  public void onModuleLoad() {

    super.onModuleLoad();

    UserAgent userAgent = GWT.create(UserAgent.class);

    if ("unknown".equals(userAgent.getRuntimeValue())) {

      // display warning

    }

}

<replace-with class="com.example.client.FallbackEntrypoint">

  <when-type-is class="com.example.client.MyEntrypoint" />

  <when-property-is name="user.agent" value="gecko1_8" /> <!-- same value as user.agent fallback -->

</replace-with>

<set-property-fallback name="user.agent" value="gecko1_8" />

Similar to what you proposed but without the <extend-property> that would cause a lot of compile-time warnings.

(note: you can even make this reusable by putting it in a gwt.xml and having MyEntrypoint be a no-op; you'd then have 2 entry-points in your app when you inherit this module, just like Logging, DocumentMode and UserAgent add their own entry-points)