Calling nsIChromeRegistry.reloadChrome() to reload the chrome, causes the reloaded chrome to have no access to XPConnect.
Oops, additional info: moz build 2000030708
Cancel that last comment, I use my own dail y build from the tip, and the build number isn't updated... =/
This bug needs to be fixed so enable dynamic locale switching
nominating on nsbeta2
[nsbeta2-],please renominate if there are scenarios where a user could encounter this.
FYI, this function gets called in swiching locale providers on the fly.
movig from architecture to browser product
Mass-moving nsbeta2- bugs to M20
I found out that probably reloadChrome() doesn't cause problem itself, but problem occurs when getService is evaluated twice
I think problem is in reloading of DOM window. Access to XPConnect is only granted for pages with URL like: chrome://xxx/content/page.xul After loading this page, URL is translated to real filesystem path like: file:///home/user/mozilla/dist/bin/chrome/packages/xxx/xxx/content/page.xul That URL does not have access to XPConnect and that cause entire problem probably.
need info: how would an NS6 user see this (steps to repro), and what exactly is the state of the app once they do? Time to either nominate for nsbeta3 (with a compelling argument for fixing this rather than some other bug we've already committed to fix), or retarget to Future.
I think this is needed for: 1. dynamic switching locales when it will be hooked (according to Tao comments) 2. developers need this for debugging their UI I don't know if this is important for nsbeta3, but now developers must disable XUL cache when developing UI
I have fix for this bug... mozilla/docshell/base/nsDocShell.cpp on line 3273 -aChannel->GetURI(getter_AddRefs(uri)); +aChannel->GetOriginalURI(getter_AddRefs(uri)); Not well tested at the moment.
[nsbeta3+] : Thank You, Jan Varga!
pulling '+' bug back from Future to M18 (as I believe was intended).
Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.
Fixed. Thanks Jan!
verified that the patch is in the tree in version 1.180.