On 15-Dec-09, at 12:48 PM, Lex Spoon wrote:
> I've now double checked on several browsers other than Opera, and I
> agree that onerror works on non-IE and onreadystatechange works on IE.
> Details here:
>
> http://blog.lexspoon.org/2009/12/detecting-download-failures-with-script.html
>
> One trick
On Tue, Dec 15, 2009 at 2:53 PM, John Tamplin wrote:
> On Tue, Dec 15, 2009 at 2:48 PM, Lex Spoon wrote:
>>
>> Ideas would be welcome about how to deal with that.
>
> Could the fragments include some JS at the end which calls a well-known "I
> loaded successfully" method?
Yes, and in fact they a
On Tue, Dec 15, 2009 at 2:48 PM, Lex Spoon wrote:
> Ideas would be welcome about how to deal with that.
Could the fragments include some JS at the end which calls a well-known "I
loaded successfully" method?
--
John A. Tamplin
Software Engineer (GWT), Google
--
http://groups.google.com/grou
Hey, Matt,
I've now double checked on several browsers other than Opera, and I
agree that onerror works on non-IE and onreadystatechange works on IE.
Details here:
http://blog.lexspoon.org/2009/12/detecting-download-failures-with-script.html
One tricky aspect is that I don't see how to get IE
On 9-Dec-09, at 1:55 PM, Lex Spoon wrote:
> On Wed, Dec 9, 2009 at 12:47 PM, Matt Mastracci
> wrote:
>> Do you know how to get onerror to fire in IE? It didn't seem to
>> work in my
>> testing.
>
> No, but why do you need it if you have onreadystatechanged? It should
> be no problem to hook
On Wed, Dec 9, 2009 at 12:47 PM, Matt Mastracci wrote:
> Do you know how to get onerror to fire in IE? It didn't seem to work in my
> testing.
No, but why do you need it if you have onreadystatechanged? It should
be no problem to hook up both callbacks.
Lex
--
http://groups.google.com/group/
On 1-Dec-09, at 6:51 AM, Lex Spoon wrote:
> On Mon, Nov 30, 2009 at 10:28 PM, Matt Mastracci > wrote:
>> 2. onerror works some of the time in some of the browsers. It
>> fails on
>> various combinations of resolve errors, error status codes and
>> other failure
>> conditions. For all browser
For clarification, I've included an approximation of what I meant by
dynamic iframe.
The idea is to create the iframe using src='javascript:;' to keep it
in the same domain as the parent iframe, use document.write() to
initialize a full HTML document inside of it, and finally, add scripts
To be clear, I don't know of any cases where people *can't* use iframes.
There are some cases where teams have chosen to use
Thanks for the test code and data, Matt! It sounds like enough
browsers are covered that error reporting is no longer a major decider
between XHR vs. script tags.
Regarding iframes, be aware that some GWT users can't use them. I
don't know all the reasons why, but one example reason is that ifra
Ray/Lex,
I'm starting to think that the dynamic iframe might not be a bad first
approach to this problem either. A single linker would be able to
provide cross-domain-capable, multi-module-safe code that doesn't
require any additional post-processing to support loading of
fragments. It a
On 1-Dec-09, at 7:51 AM, Lex Spoon wrote:
> On Mon, Nov 30, 2009 at 10:28 PM, Matt Mastracci > wrote:
>> 2. onerror works some of the time in some of the browsers. It
>> fails on
>> various combinations of resolve errors, error status codes and
>> other failure
>> conditions. For all browser
On Mon, Nov 30, 2009 at 10:28 PM, Matt Mastracci wrote:
> 2. onerror works some of the time in some of the browsers. It fails on
> various combinations of resolve errors, error status codes and other failure
> conditions. For all browsers (except Opera) that don't support it directly,
> It can be
Sure, I'd love to take a look at it. I've got a basic version of
globally-scoped, cross-domain code-splitting up and running that uses
simple script-tags for the cross-domain load right now.
Re:
Lex,
JSONP loading + dynamic iframe seems like a straightforward viable option
that doesn't require a lot of complicated compiler work, what do you think
of providing this as an option?
-Ray
On Mon, Nov 30, 2009 at 12:29 PM, Lex Spoon wrote:
> (Reposting to get it on the mailing list; first t
(Reposting to get it on the mailing list; first try bounced.)
Hey, Matt,
I agree with your analysis about the code-splitting issues.
I've worked out a preliminary patch to do var renaming, but I haven't
shared it yet because it's in a pretty early state. I could share it
if you or someone is e
I put some thought into this last night and there are some interesting
questions raised:
By default, the IFrameLinker allows multiple modules to coexist on
the same page. To replicate this with scripts, you need to ensure that
all scripts are privately scoped. There are conflicts with priv
err, not explicit scope, I mean "predeclare all your symbols with 'var'
privarte scope".
-Ray
On Tue, Nov 24, 2009 at 11:29 PM, Ray Cromwell wrote:
>
> IMHO, pollution of the global namespace is a big problem for general
> purpose apps. It's ok to do it when you control everything (e.g. Wave),
IMHO, pollution of the global namespace is a big problem for general purpose
apps. It's ok to do it when you control everything (e.g. Wave), but probably
a bad idea for enterprise users who have a habit of composing lots of small
GWT modules on a single dashboard. We probably need to support both e
On Tue, Nov 24, 2009 at 9:39 PM, Matt Mastracci wrote:
> Hey Scott,
>
> I've ported hosted.html over to hosted.js a few times and it's not actually
> a problem. The only significant differences between the two files are
> s/parent/window/ and how you pass the name of the module to the hosted-mode
Hey Scott,
I've ported hosted.html over to hosted.js a few times and it's not
actually a problem. The only significant differences between the two
files are s/parent/window/ and how you pass the name of the module to
the hosted-mode bootstrap script. Each version of the plugin tested
(Saf
I think this is a good direction to be heading in. It's a bit non-trivial,
though, because the plugin expects to be nested in an iframe. I'm sure
that's solvable, but it will be some work.
On Tue, Nov 24, 2009 at 6:38 PM, Matt Mastracci wrote:
> Hey all,
>
> If I recall correctly, the original
Hey all,
If I recall correctly, the original reason that GWT used iframe-
wrapped scripts was to work around the buggy compression of Javascript
some early versions of IE (example:
http://support.microsoft.com/default.aspx?scid=kb;en-us;823386&Product=ie600)
.
The number of users on IE 6 SP1
23 matches
Mail list logo
