32661 - nsIChromeRegistry.reloadChrome() leaves chrome in a state where access to XPConnect is denied

Status: VERIFIED FIXED

(Core Graveyard :: RDF, defect, P3)

Description

[Martijn Pieters]

Calling nsIChromeRegistry.reloadChrome() to reload the chrome, causes the
reloaded chrome to have no access to XPConnect.

Comment 1

[Martijn Pieters]

Attachment: Testcase

Comment 2

[Martijn Pieters]

Attachment: Working testcase (how did that typo get there?)

Comment 3

[Martijn Pieters]

To reproduce:

1. save (second, correct) testcase in chrome/test/content/default/6741.xul
2. fire up mozilla -chrome chrome://test/content/6741.xul
3. click Test->Reload
4. Mozilla reloads chrome.
5. click Test->Reload
6. Console gives "JavaScript Error: uncaught exception: Access denied to
XPConnect service."

Expected mozilla to reload chrome again.

Comment 4

[Martijn Pieters]

Oops, additional info: moz build 2000030708

Comment 5

[Martijn Pieters]

Cancel that last comment, I use my own dail y build from the tip, and the build
number isn't updated... =/

Comment 6

[tao]

This bug needs to be fixed so enable dynamic locale switching

Comment 7

[Peter Trudelle]

nominating on nsbeta2

Comment 8

[Peter Trudelle]

[nsbeta2-],please renominate if there are scenarios where a user could 
encounter this.

Comment 9

[tao]

FYI, this function gets called in swiching locale providers on the fly.

Comment 10

[Dawn Endico]

movig from architecture to browser product

Comment 11

[Peter Trudelle]

Mass-moving nsbeta2- bugs to M20

Comment 12

[Jan Varga [:janv]]

I found out that probably reloadChrome() doesn't cause problem itself, but
problem occurs when getService is evaluated twice

Comment 13

[Jan Varga [:janv]]

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.

Comment 14

[Peter Trudelle]

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.

Comment 15

[Jan Varga [:janv]]

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

Comment 16

[Jan Varga [:janv]]

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.

Comment 17

[Peter Trudelle]

[nsbeta3+] : Thank You, Jan Varga!

Comment 18

[John Morrison]

pulling '+' bug back from Future to M18 (as I believe was intended).

Comment 19

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 20

[Jan Varga [:janv]]

Attachment: proposed patch

Comment 21

[David Hyatt]

Fixed.

Thanks Jan!

Comment 22

[shrirang khanzode]

verified that the patch is in the tree in version 1.180.