Kevin: I still suspect it is GC related, but maybe I'm grasping at straws. Can you give a recent trunk release a try. Here is the list:
http://build.chromium.org/buildbot/snapshots/chromium-rel-xp/ Just try the latest one. - a On Thu, Oct 8, 2009 at 6:59 PM, kevin <[email protected]> wrote: > > Created http://code.google.com/p/chromium/issues/detail?id=24393 > > While reducing the size of my extension for this bug, I think frame > and multiple content scripts are not required factors; they just make > the problem more obvious -- occurs immediately instead of waiting for > indefinite time. It sounds likely related to GC, but the code Aaron > suggested does not help, and today's push (4.0.221.6) does not work > either. > I hope you still find the bug interesting. > (I think the role that frame played in my earlier test is similar to > the step of opening new tab, which is required in the bug I created.) > > On Oct 8, 10:39 am, Matt Perry <[email protected]> wrote: >> This sounds like an interesting bug. Could you file a report at >> crbug.comwith an attached test case that demonstrates the issue? >> >> On Thu, Oct 8, 2009 at 9:57 AM, kevin <[email protected]> wrote: >> >> > I added the two lines in my content script. It didn't solve my >> > problem, but it helped me reveal another factor in my problem: >> > I have two content scripts, both matching http://*/*, and opening a >> > port for different functionality. When testing your suggestion, I >> > disabled one content script, and it worked. >> > So my problem has two necessary factors: multiple frames AND multiple >> > content scripts. >> >> > I could work around by combining the two content scripts, but I prefer >> > not to do it as it somehow violates separation of concern. I'll do it >> > if there's performance difference, or my problem cannot be fixed (in >> > this case a clear explanation is appreciated). >> >> > On Oct 7, 7:08 pm, Aaron Boodman <[email protected]> wrote: >> > > I believe that this is due to a bug which I've just checked in a fix for. >> > > The issue was that we would sometimes GC content scripts if they didn't >> > mak >> > > a reference from the document to the content script. You can test if this >> > is >> > > the problem by doing something like: >> >> > > function dummy() { } >> > > window.addEventListener("load", dummy, false); >> >> > > If this makes it work, it is probably the bug I'm talking about, and it >> > will >> > > be fixed in the next dev channel release. >> >> > > - a >> >> > > On Wed, Oct 7, 2009 at 7:05 PM, Kevin Jin <[email protected]> wrote: >> >> > > > I have a content script which opens a port to the extension. It works >> > > > fine on pages w/o frames, but for any page that contains frames, such >> > > > as this simple one: >> > > > top.html: >> > > > <iframe src="frame1.html"></iframe> >> > > > frame1.html: >> > > > <h1>frame1</h1> >> > > > <script> >> > > > if (window == top) { >> > > > document.write('<h2>window == top</h2>'); >> > > > } >> > > > </script> >> >> > > > The port is disconnected unexpectedly -- my extension receives >> > > > port.onDisconnect once top.html is loaded. >> > > > I do use the window == top test in my content script so that it >> > > > creates port only for top, not frame1. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-extensions" 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/chromium-extensions?hl=en -~----------~----~----~----~------~----~------~--~---
