OK, we all know that Google rolled out some changes to iGoogle a
couple of weeks ago that broke a bunch of our gadgets. Unfortunately,
they've been silent about what those changes were, and to make matters
worse they've not been rolled out universally - meaning that we have a
shedload of users complaining that our gadgets are broken, but often
we developers can't see the problems, and therefore can't even try to
fix them.
Finally, I have a bit of good news. This morning I was able to get my
hands a "new" version of one of my gadgets, figure out what Google had
done to it, and implement a fix. This is a long post, but stick with
it if you've been burned by this change, and hopefully it will help
you out.
Here's a simplified gadget that will demonstrate the problem:
<?xml version="1.0" encoding="UTF-8"?>
<Module>
<Require feature="dynamic-height"/>
<Content type="html"><![CDATA[
<h1>
My Gadget
</h1>
<p id="text"></p>
<style type="text/css">
h1,
p {
font-size: 80%;
text-align: center;
margin: 2px 0 0 0;
}
</style>
<script type="text/javascript">
_IG_FetchContent('http://example.com/ajax.php', function (text)
{
_gel('text').innerHTML = text;
_IG_AdjustIFrameHeight();
});
</script>
]]></Content>
</Module>
Simple enough, it dynamically loads some content into an HTML element
from an AJAX call . Up until recently, this gadget would have run (and
formatted) fine. In the iframe on iGoogle, the <body> would have
looked just like the <Content> above.
However, here's the big change: with the new iGoogle renderer, the
Content gets "minified" before it gets sent to the client, presumably
to decrease latency. So, the new body content looks like this:
<h1>
My Gadget
<p id="text">
<style>h1,p{font-size:80%;text-align:center;margin:2px 0 0 0;}</style>
<script type="text/javascript">
_IG_FetchContent('http://example.com/ajax.php', function (text) {_gel
('text').innerHTML = text;_IG_AdjustIFrameHeight();});
</script>
Several things have happened here:
- Leading whitespace has been trimmed.
- The closing HTML content tags have been removed (</h1> and </p>).
- Virtually all whitespace has been removed from the <style> element.
- Most whitespace has been removed from the <script> as well.
In theory, this should all be fine - the whitespace is superfluous,
and the browser should assume the closing HTML tags. And in fact, the
gadget will render fine when it first loads.
The problem comes in the callback for _IG_FetchContent(). In my code,
the _gel('text').innerHTML call would replace everything between the
opening <p id="text"> and clsoing </p> tags. However, because there's
no closing </p> tag, EVERYTHING after <p id="text"> gets replaced -
including my <style> and <script>!
Boom, the gadget falls apart. The CSS no longer exists - in this case,
it'll just make my content look crappy, but for a more complex gadget
it could break much more seriously. Worse, my JavaScript is also gone;
this means the _IG_AdjustIFrameHeight() call never happens (sound
familiar?), and any other functionality I might have put in there is
also out the window.
And this innerHTML bug is only one specific problem that I
encountered. I have little doubt that there are other, equally bad
side effects to this new iGoogle code. For example, what if I'd left
off some semicolons in my JS? If it had still been minified in the
same way, it would have broken too.
What's the solution?
Obviously, Google should (1) roll back the changes, (2) stop minifying
our code so aggressively, and (3) deploy a new version in the
developer sandbox before the live environment. But they seem to have
abandoned us on this issue, so we need to take matters into our own
hands.
My first recommendation to other developers is to move all <style> and
<script> blocks to the beginning of the <Content> section, BEFORE any
visible HTML content tags. This should fix the specific innerHTML
problem described above.
Second, try removing all your closing content tags (like </p> and </
div>) manually, and see how your gadget works. Ideally, you'd also
strip all your whitespace - but that's a real PITA, both to do
initially and to try to maintain.
Third, post back here with your own findings. Since we've all been
hung out to dry by Google on this, we might as well hang together. :^)
Good luck!
String
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"iGoogle Developer Forum" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/Google-Gadgets-API?hl=en
-~----------~----~----~----~------~----~------~--~---
