Hi String, I was testing your code more for the sake of determining whether gadgets.* was breaking everything rather than content-rewriting breaking everything (since the rollouts would be separate). I wasn't able to see your gadget rendering with rewriting, as I'm not in whatever experiment is triggering those results. However, gadgets.* is now, unofficially at 100%, so I think we can safely rule that out as the cause. I'm not ready to tell everyone to start using it as their sole development platform, just in case it were to be rolled back, but it's here.
To add some more light to this discussion, it's looking more like a rewriting issue is at play here, but it's actually not the OS/ gadgets.* rewriting. It's likely a smaller set of rewriting rules called html-compactor, which are also in an experiment (which is why I'm not seeing them). This has triggered an internal discussion on why isn't html-compactor part of content-rewriter, why isn't it tested in the sandbox, and how can we (or at least I, in order to verify results you are all seeing) verify problems being caused by this experiment. I'll try and get more details on html-compactor, and see if we can resolve any issues it's causing over the next few days. On the bright side, rollouts like this should be few and far between (if there are even any more of them). Most developer-facing changes will be tied to the code (based on Shindig) that's driving the sandbox, so you will be able to test there, before the features come to production. Dan On Jun 22, 2:35 pm, String <[email protected]> wrote: > Hi Dan, > > Glad to have you back. Let me just say that I have no issue with you > personally - you certainly deserve a vacation - but I do still have > issues with Google on some of these fronts. > > But, moving on to the issue at hand. The code I posted in this thread > was just an example I made up to demonstrate the scenario; the actual > gadget where I saw these issues is a lot more complicated. And the > issues were definitely intermittent; the gadget was fine on my iGoogle > but broken for some users, but broken on syndication for me as well - > unless I added nocache=1 to the url, at which point it worked again. > I'd be interested to know how you forced the rewriting to happen in > your test environment. > > Also, my gadget's problem was due to its <style> being overwritten - > sorry if that wasn't clear in my original post. The comment about > dynamic-height was just conjecture, although one that makes sense in > light of the evidence I saw. My gadget was definitely also losing some > JS as a result of this problem. Can I ask, when you ran my sample > gadget with content-rewriting on, what happened to its CSS? > > And it's also good news that we can turn this off (with the OS > rewriter controls) - although that's less important now that we know > what the problem is, and can restructure code to avoid it. > > Finally, your explanation of this being due to "a content-rewriting > experiment and not a gadgets.* experiment" makes perfect sense to me. > I can't dispute which Google experiment broke this code. But my later > point stands: why are these experiments being done in the live > environment? Why were they not trialled in the sandbox? > > Thanks, > > String > > 2009/6/22 Dan (Google) <[email protected]>: > > > > > On further reflection, it's because the <Require> tag was not inside > > the required <ModulePrefs> section of the gadget code that was posted. > > With that added, the gadget works fine (assuming it fetches a valid > > page). I'm not seeing the dynamic-height issue at all. > > > Dan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
