Though adding the code "window.addEventListener('load', dummy,
false)" did not help, I think the fix applied to this case -- this
problem is gone in build 28508.
Thanks!On Oct 8, 7:05 pm, Aaron Boodman <[email protected]> wrote: > 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: > > > Createdhttp://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 -~----------~----~----~----~------~----~------~--~---
