On 9/7/07, Matthew Gertner <[EMAIL PROTECTED]> wrote: > > Reloading chrome means losing any changes that were made to it by > > scripts, as well as the script's state. > > Right, well you would rerun all the relevant scripts when you reload the > overlays. Basically I'm proposing an intermediate stage which would be > basically restarting Firefox but without the restarting Firefox part > (i.e. no need to quit and restart the actual OS process). > In particular, you lose your open tabs in the browser, which have to be reopened after the chrome is reloaded. Whenever our session store or necko cache implementation is imperfect, you lose data. It's better to let the user restart the application explicitly, because he expects to hit the session store quirks when he does.
> >> A second phase might be to include hints in overlays about what they > >> might affect (reducing the scope of what has to be reloaded) and/or > >> deducing this programatically. This strikes me as far better than having > >> to restart Firefox. > > > > I don't see how it's different from document.loadOverlay. > > Can you explain in a bit more detail how your solution using > document.loadOverlay would work? > I'm not sure we're talking about the same thing. My point is pretty obvious - pretty much any overlay [if we forget about dynamic overlay bugs] can be loaded both at the document load time and dynamically via document.loadOverlay. The result would be similar, except: 1. the overlay scripts that may be relying on the "load" event won't get it, and 2. if some script modified the overlay points (e.g. removed the Tools menu you're overlaying or changed its id or anything like that), the overlay won't get fully applied. Nickolay P.S. this is quite off-topic for dev-xpcom, but I'm not too worried since this group is getting closed in a day anyways :) _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
