String, that's some stellar detective work. Based on what you've found, I'm starting to thing that the new random behavior of _IG_AdjustIFrameHeight() on iGoogle might be caused by the "minified" removal of the end tags. Sometimes it fires, sometimes it doesn't, and sometimes it fires but doesn't make the frame large enough for all the content. (As in my code at http://hosting.gmodules.com/ig/gadgets/file/114281111391296844949/driving-directions.xml) Could _IG_AdjustIFrameHeight() be getting confused by the lack of fully-formed DOM elements?
On Jun 22, 5:13 am, String <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
