2.7.0-beta1 deferredjs bypasses application cache

[Richard Wallis]

I've got an offline capable gwt app that uses html5 appcache.

When compiled with 2.7.0-beta1 gwt skips the cache when loading deferred js files.

I've attached screenshots of the different network activity between 2.6.1 and 2.7.  You'll see that 16.cache.js and 2.cache.js are not loaded from cache in 2.7.

16.cache.js and 2.cache.js are both correctly cached and I can visit them while disconnect from the internet.

But when I run the app itself while disconnected, I just get network errors and the app does not work.

[Richard Wallis]

ok, it seems that in gwt 2.6 the deferred scripts are fetched by an xmlhttprequest and in 2.7 they're injected into head.

Is that correct?  Have some new security features been added that force a fetch from the server?

Where can I find out what changes have been made to how deferredjs files are loaded?

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4107c532-7aa9-47af-885d-c2acefb465d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thomas Broyer]

IIRC, Brian changed the behavior of the xsiframe linker to match the direct-install linker, because most browsers would otherwise not display the source maps. There should be flag to turn it off and go back to the previous behavior.
It however looks like a browser bug worth reporting.

[Richard Wallis]

Thanks Thomas,

<add-linker name="std" /> fixes the issue.

It does seem like it might be a browser bug.  It shouldn't be possible to ever bypass the cache I don't think.

I tried to build a small gwt program to reproduce the error but my small program worked perfectly.

Still recurs everytime in the app where I found the problem though.

On Mon, Oct 20, 2014 at 10:49 PM, Thomas Broyer <t.br...@gmail.com> wrote:

IIRC, Brian changed the behavior of the xsiframe linker to match the direct-install linker, because most browsers would otherwise not display the source maps. There should be flag to turn it off and go back to the previous behavior.
It however looks like a browser bug worth reporting.

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b46f94bc-4dc3-45f1-822f-d2df59f7cc8a%40googlegroups.com.

[Thomas Broyer]

On Monday, October 20, 2014 10:49:13 PM UTC+2, Thomas Broyer wrote:

IIRC, Brian changed the behavior of the xsiframe linker to match the direct-install linker, because most browsers would otherwise not display the source maps. There should be flag to turn it off and go back to the previous behavior.

 

Here's the commit that changed xsiframe behavior: https://gwt.googlesource.com/gwt/+/ab905f749cb81e930c9240f3c67acbcf96a4a4e2

It actually depends (by default, if not overridden) whether you use -style PRETTY (or DETAILED) or not (i.e. OBF or OBFUSCATED)

See https://code.google.com/p/google-web-toolkit/issues/detail?id=8578#c5 for the rationale.

 

[Richard Wallis]

Thanks,

just checked and <set-configuration-property name="installCode" value="true" /> also fixes the problem, so I'll use that instead of adding the linker.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/ee970214-9fd0-46be-aa9a-17cb299d491b%40googlegroups.com.

[Richard Wallis]

Just an update in case someone else runs into this issue installCode = true does not fix the problem, I'm back to adding std linker.