User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.124 Safari/537.36 Steps to reproduce: Run this command to launch Firefox: "firefox -chrome http://music.google.com" Actual results: The page doesn't load and only shows some raw HTML: <iframe src="https://fls.doubleclick.net/activityi;src=2542116;type=andro238;cat=googl515;ord=1;num=1?" width="1" height="1" frameborder="0" style="display:none"></iframe> Expected results: http://music.google.com should load as normal

You told Firefox to use that website as the chrome (app) URL in a toplevel window. Behaviour at that point is pretty much undefined. Don't pass the -chrome switch with a remote URL.

Dan, seeing as you last touched this (apart from the preferences hack for in-content prefs) - beyond tests using this with file:// paths, what's the usecase for this flag and is there any reason not to board up everything but file: and chrome: URIs ?

Ahh, I misunderstood the reason for this flag. I believed it to be a flag that was meant to run Firefox without its Chrome (tabs, address bar, etc).

The -chrome param is ancient, used to launch into UIs other than the default browser (e.g. Chatzilla or parts of the "Mozilla Suite" at the time). Required when launching a XULRunner app since the app's chrome could be anything. I certainly wouldn't mind this being locked down more. I think we might need to support resource: in addition to chrome: (there's a lot of add-ons out there -- I bet SOMEone is doing that), and if you say tests are using -chrome file: then I guess we need that, too.

Bug 1175653 - only allow local schemes for the chrome commandline flag, r?dveditz

https://reviewboard.mozilla.org/r/12049/#review10789 Looks good. If you're whitelisting the three schemes chrome,file,resource then you don't really need to check if it's a data: or javascript: url anymore (what the URI_INHERITS_SECURITY_CONTEXT check is doing). If you wanted to you could use the same kind of URIChainHasFlags() check for URI_IS_LOCAL_RESOURCE, but that includes data: so you'd definitely want to keep the "if (isLocal)" check that it doesn't inherit. URIChainHasFlags() walks through nested URI types so if you don't do that then you definitely need to keep getting the innermost URI as your patch does. r=dveditz

Comment on attachment 8626292 [details] MozReview Request: Bug 1175653 - only allow local schemes for the chrome commandline flag, r?dveditz https://reviewboard.mozilla.org/r/12051/#review10791 Ship It!

https://hg.mozilla.org/mozilla-central/rev/22caff946154 https://hg.mozilla.org/mozilla-central/rev/d16792c5d1ed https://hg.mozilla.org/mozilla-central/rev/6ce164c7c50a

When testing this with a remote URL on the command line I received: *** Preventing load of web URI as chrome If you're trying to load a webpage, do not pass --chrome. Then firefox launched with the normal start page. I proceeded to test this with a local file:// URI with the expected results, as with a chrome:// URI. If someone can point me in the direction of an add-on to be launched with a resource:// URI I'll update this to confirm that it works as expected too.