[gwt-contrib] Re: Unsupported browsers
> > And as already noted the onPropertyErrorFn functions works slightly > different than what I would expect thats why I called it unreliable. It > only works if you use a browser that GWT does not know at all. > To be exact: The method itself is of course reliable. It triggers if a property value is not valid, i.e. if its not in the set of defined/allowed values. It's just that its not that useful for the user.agent scenario as a slightly different behavior is desired in this case because the user.agent value is always correctly filled (regardless of permutations) unless you use a browser that is totally unknown to GWT. -- J. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Unsupported browsers
>
> In this case, onLoadErrorFn would be called IIRC. Are you saying
> onLoadErrorFn is not reliable?
>
onLoadErrorFn is only called if an unexpected exception occurs while
starting an already selected permutation, so for example if onModuleLoad()
fails. Each permutation defines a gwtOnLoad function which looks like
function gwtOnLoad(errFn, modName, modBase, softPermutationId){
$moduleName = modName;
$moduleBase = modBase;
if (errFn)
try {
$entry(init)();
}
catch (e) {
errFn(modName);
}
else {
$entry(init)();
}
}
with errFn being the onLoadErrorFn function passed in by the bootstrap
script and $entry(init)() does a user agent runtime check and then executes
onModuleLoad(). So this function works reliably but does not really help
for unsupported browsers because if no permutation is selected this code
can't be executed.
And as already noted the onPropertyErrorFn functions works slightly
different than what I would expect thats why I called it unreliable. It
only works if you use a browser that GWT does not know at all.
-- J.
--
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-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Unsupported browsers
On Wednesday, November 27, 2013 11:13:03 AM UTC+1, Jens wrote:
>
>
>> There's "gwt:onPropertyErrorFn" and "gwt:onLoadErrorFn" hooks (set the
>> name of a JS func in a with that name; e.g. > name="gwt:onPropertyErrorFn" value="gwtErrFns.prop">, and var gwtErrFns = {
>> prop: function(propName, allowedValuesList, value) {
>> window.location.replace("static/error.html"); } })
>>
>
> I know. But they are not reliable. If you disable IE6 and IE8 permutation
> the bootstrap file still assigns a valid ie6, ie8 value to the user.agent
> property because the user.agent detection code does still contain the
> ie6/ie8 checks. onPropertyErrorFn will only be called if the user.agent
> value contains an invalid value. So to make it work way better the
> detection code should be aware of the enabled/disabled permutations and
> only do the required checks instead of all checks. That way the
> onPropertyErrorFn function would become useful for this scenario.
>
If that's the case, then it means a PropertyProviderGenerator is called
with the full list of possible values even when that list is restricted to
a subset of them with . I'd say it's a bug.
That said, it wouldn't be enough in some cases: imagine using a conditional
set-property where ie9,gecko1_8 are enabled for locale=en and ie9,safari
are enabled for locale=fr, the property provider would have to return
either gecko1_8 or safari, and then depending on the locale a permutation
would be found or not; which would be the same behavior as we have today if
you disable a user.agent globally. In this case, onLoadErrorFn would be
called IIRC. Are you saying onLoadErrorFn is not reliable?
(in all honesty, I never used them, I only ever read the code that calls
them, and I haven't checked the exact behavior)
--
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-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Unsupported browsers
>
>
> There's "gwt:onPropertyErrorFn" and "gwt:onLoadErrorFn" hooks (set the
> name of a JS func in a with that name; e.g. name="gwt:onPropertyErrorFn" value="gwtErrFns.prop">, and var gwtErrFns = {
> prop: function(propName, allowedValuesList, value) {
> window.location.replace("static/error.html"); } })
>
I know. But they are not reliable. If you disable IE6 and IE8 permutation
the bootstrap file still assigns a valid ie6, ie8 value to the user.agent
property because the user.agent detection code does still contain the
ie6/ie8 checks. onPropertyErrorFn will only be called if the user.agent
value contains an invalid value. So to make it work way better the
detection code should be aware of the enabled/disabled permutations and
only do the required checks instead of all checks. That way the
onPropertyErrorFn function would become useful for this scenario.
-- J.
>
--
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-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: GWT 2.7.0-SNAPSHOT in Google maven snapshot repo
On Wed, Nov 27, 2013 at 1:40 AM, Thomas Broyer wrote: > Just to be sure: this is not automatized yet, right? > Not fully: I've got it mostly scripted, but it still needs me to manually run it and enter a few values. Assuming it's working, I'll try to automate it or at least setup a calendar reminder to nag me to run it daily. :) Thanks again to Colin for getting the maven scripts working for snapshots! -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: GWT 2.7.0-SNAPSHOT in Google maven snapshot repo
On Wednesday, November 27, 2013 1:03:26 AM UTC+1, Matthew Dempsky wrote: > > FYI, I've pushed out a build of master to Maven as 2.7.0-SNAPSHOT. > \o/ I won't have a use for it right now (except maybe updating the Maven plugin proactively and pushing snapshots as well), but thanks a lot for that anyway. Just to be sure: this is not automatized yet, right? > Not sure if the next release will be "2.7", but it needed *some* version > and that seemed as good as any. > Yup, seems like the best choice to date. -- 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-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Unsupported browsers
On Wednesday, November 27, 2013 1:13:30 AM UTC+1, Jens wrote:
>
> Currently, when a browser is unsupported (incl IE compatibility modes),
>> GWT falls back to gecko1_8. The problem is Firefox itself has its own bugs
>> and we have workarounds for those that will usually break the app in an
>> other browser.
>>
>
> Are you sure? In our app we have removed the ie6/7 user.agent value and
> when visiting our app with IE6/7 or IE compatibility mode no permutation is
> selected. Thats why we configured a redirect to a static site in your load
> balancers. Is it possible that we have somehow accidentally disabled this
> gecko1_8 fallback mechanism?
>
I agree, I don't recall seeing anything related to falling back to
gecko1_8, and UserAgentPropertyGenerator has a "return 'unknown'" as a
fallback when no predicate matches.
Goktug, are you sure it's not an issue with your Server-Side
Selection-Script?
>
>
>> Instead of relying gecko1_8 as the fallback permutation, perhaps we can
>> provide a specific permutation for unsupported browsers. With this
>> permutation, most of the we can provide the standard implementation in
>> deferred bindings. The biggest advantage of this is, the app can handle it
>> in a way they see appropriate; e.g. provide an early shortcut to show a
>> warning page.
>>
>> Also another thing we might want to do is to make sure that an IE
>> permutation is used for the legacy browsers; IE8 would be a much better
>> match than gecko for IE6/7 and any compatibility mode.
>>
>
> Falling back to a standards based permutation will be nice for new/unusual
> browsers that might work with GWT but are not detected by GWT. Falling back
> to an IE8 permutation for IE6/7 might work now but in a year IE8 is
> probably gone anyways so I am not sure if its worth it. Also although the
> JS code might work then, the UI is likely to not work very well if IE6/7
> specific UI code has been deleted.
>
> What I like to see is something like:
>
> 1.) A way to ask GWT at runtime if it runs in a fallback permutation
> because it has failed to detect the browser (may it be a standards based
> permutation or for IE a specific IE fallback permutation). This would allow
> an app to provide a warning message. This is kind of an optimistic approach
> as it could also happen that the app does not load at all.
> 2.) A way to configure a redirect URL if GWT can not detect the browser
> (or the browser is unsupported). That would be the pessimistic approach.
>
There's "gwt:onPropertyErrorFn" and "gwt:onLoadErrorFn" hooks (set the name
of a JS func in a with that name; e.g. , and var gwtErrFns = {
prop: function(propName, allowedValuesList, value) {
window.location.replace("static/error.html"); } })
> 3.) A configuration property for developers to tell GWT if it should
> choose approach 1.) or 2.)
>
>
> -- J.
>
>>
--
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-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
