1175653 - Launching Firefox with the -chrome flag should ignore non file, non-chrome URLs passed

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Jacob Lauer]

Attachment: 2015-06-17 12_45_24.jpg

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

Comment 1

[:Gijs (he/him)]

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.

Comment 2

[:Gijs (he/him)]

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 ?

Comment 3

[Jacob Lauer]

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).

Comment 4

[Daniel Veditz [:dveditz]]

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.

Comment 5

[:Gijs (he/him)]

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

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

Comment 6

[Daniel Veditz [: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 7

[Daniel Veditz [: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!

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/22caff946154

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/d16792c5d1ed

Comment 10

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/6ce164c7c50a

Comment 11

[Phil Ringnalda (:philor)]

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

Comment 12

[Cody Crews]

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.