hey guys I've isolated the code that was causing me those Gmail problems. it was unnecessarily being called in the load completed callback code, so I just removed it. But I'm still a little confused as to why it was causing problems
The code in question that was being triggered handles our GTK+ controls on screen, so if the current uri matches one from a whitelist for fullscreen pages, then we hide our browser tool and status bars. Some pages can be configured to display just the status bar or just the toolbar or have the onscreen keyboard popup automatically etc. It's pretty simply code and really just calls gtk show/hide on various controls, however, it was also doing a flush of any pending GTK+ events I'm wondering if that was what was triggering the problems with gmail ? I'll do some further tests on this tomorrow. -- Glen Gray [EMAIL PROTECTED] On 2 May 2008, at 15:42, Glen Gray wrote: > User-Agent string was one of the first things I looked at. The example > CNN Video that Steve Lu mentioned yesterday for example, won't play > with out standard user-agent string but does when left unmodified. > > > -- > Glen Gray > [EMAIL PROTECTED] > > > > > On 2 May 2008, at 14:37, Grant Gayed wrote: > >> Hi Glen, >> >> There was a problem until recently in SWT's Safari-based Browsers >> when >> accessing gmail and google calendar because they look for certain >> user-agent >> strings in the request header to decide what to enable. Embedding >> cases may >> not have these strings if they are added by the browser (eg.- >> "Firefox/...") >> as opposed to the renderer (eg.- "Gecko/..."). I don't know if this >> is what >> you're seeing, but I see some similarity in your description. The >> swt bug >> report is https://bugs.eclipse.org/bugs/show_bug.cgi?id=220836. >> >> HTH, >> Grant >> >> >> "Glen Gray" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >>> Thanks Chris, >>> >>> I am glad though, as it means it's a problem in code that I'm >>> comfortable with and I've a working reference point. >>> >>> I'm getting swamped with some other stuff at the moment so I >>> probably >>> won't get to finish this off today. But the plan is to strip it >>> right >>> back in my code and build it up again to see if I can isolate it. >>> I'm >>> sure I'll have a few questions about some of the API's that I didn't >>> recognize, so you'll still be hearing from me. >>> >>> Regards, >>> -- >>> Glen Gray >>> [EMAIL PROTECTED] >>> >>> >>> >>> >>> On 2 May 2008, at 13:27, Christopher Blizzard wrote: >>> >>>> Glen Gray wrote: >>>>> Ok, thanks to Chris's IRC prompting yesterday, I rebuilt xulrunner >>>>> with --enable-tests (on F9, firefox's --enable-tests doesn't do >>>>> anything for GtkMozEmbed testing, it has to be xulrunner). >>>>> >>>>> After a long re-build, I was able to test with TestGtkEmbed. I'm >>>>> pleased to say that TestGtkEmbed DOESN'T exhibit the problem. >>>>> This is >>>>> good news for me as it means I've a reference implementation to >>>>> compare API calls with and see if I'm doing anything stupid or >>>>> missing >>>>> anything in my initialization of the browser. >>>>> >>>>> I'll keep you posted as to any further progress I make with my own >>>>> code base. >>>>> -- >>>> >>>> I'm actually sad that it wasn't easy to reproduce in TestGtkEmbed. >>>> Now >>>> we can't help you track it down. :( >>>> >>>> --Chris >>>> _______________________________________________ >>>> dev-embedding mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-embedding >>> >> >> >> _______________________________________________ >> dev-embedding mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-embedding > > _______________________________________________ > dev-embedding mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-embedding _______________________________________________ dev-embedding mailing list [email protected] https://lists.mozilla.org/listinfo/dev-embedding
