113994 - local (file://) sidebar doesn't load (checkloaduri failure)

Status: RESOLVED WORKSFORME

(SeaMonkey :: Sidebar, defect)

Description

[Bill Nottingham]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112017

If I set up a local sidebar directly in panels.rdf, i.e.:

...
<RDF:Description about="urn:sidebar:panel:moof"
                   NC:title="moof"
                   NC:content="file:///some/where/test.html" />
<RDF:Seq about="rdf:#$1YJV22">
    <RDF:li resource="urn:sidebar:panel:search"/>
    <RDF:li resource="urn:sidebar:panel:bookmarks"/>
    <RDF:li resource="urn:sidebar:panel:moof" />
 </RDF:Seq>
 ...

when it tries to load, it fails with the javascript error:

'The link to file://some/where/test.html was blocked by the security manager.
Remote content may not link to local content.'

I don't see any remote content here, unless I'm really misunderstanding
something. I can understand why you don't want code on a remote site to add a
local sidebar panel, but this is a panel that's already 'added', per se.

Might be a dupe of 48583; I'm not sure if this is related to the addPanel()
cases or not.

Reproducible: Always
Steps to Reproduce:
1. add sidebar with file:// url in panels.rdf
2. attempt to view sidebar

Actual Results:  Fails with error...

Expected Results:  Succeeds, of course. ;)

Comment 1

[Samir Gehani]

Confirmed.  Over to Security.

Comment 2

[Samir Gehani]

*** Bug 120864 has been marked as a duplicate of this bug. ***

Comment 3

[Eric A. Meyer (dead account)]

Flipping this to All/All since it's also happening under MacOS and Win2KPro, at
a minimum.  Here's what a Win2KPro attempt at a local-sidebar installation
coughed up:

uncaught exception: [Exception... "'Script attempted to add sidebar panel from
illegal source' when calling method: [nsISidebar::addPanel]"  nsresult:
"0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame ::
file:///C:/temp/index.html :: addTab :: line 16"  data: no]

Comment 4

[basic]

Eric: I think your issue is related but not the same as the one reported in this
bug. Your issue can be fixed by the fix that will (hopefully someday be written
to) fix bug 4858 (but you will find this issue instead). However I doubt that
fix will fix this issue.

Bill: have you tested loading the sidebar while a file url is loaded? If I'm not
mistaken I think that the way checkloaduri is currently implemented it only
allows a file url content to load a file url. I think the issue might be that
the sidebar treats the current loaded content in the browser as its source and
the sidebar panel url as its target. Which would mean that one cannot load a
file url if the current loaded page is not loaded from a file url
(chrome/resource/about/... wouldn't work, it must be "file").

Comment 5

[basic]

Then again I could be wrong again. Anyone familiar with how the browser loads a
page?

Comment 6

[Christophe Thalet]

see related Bug 151579

Comment 7

[matt wilkie]

Possible workaround: go through http://localhost/ instead?

Comment 8

[Brian Vetter]

Localhost is not a workaround. I don't want to run a web server on my client
computer.

Comment 9

[Vidar Haarr (not reading bugmail)]

*** Bug 151579 has been marked as a duplicate of this bug. ***

Comment 10

[Daniel Wang]

*** Bug 155604 has been marked as a duplicate of this bug. ***

Comment 11

[Matthias Versen [:Matti]]

*** Bug 218131 has been marked as a duplicate of this bug. ***

Comment 12

[benc]

basic:
the sidebar loader seems to call checkloadurl, which is used to block loading
file URL's. The idea is to prevent the loading of file URL's when the source is
insecure.

I think this is unneeded and incorrect for two reasons.

1- The use of a file: url for a sidebar is valid in some situations.
2- There is no way for sidebars to be added that have file URL's already,
because of:

function sidebarURLSecurityCheck(url)
{
    if (url.search(/(^http:|^ftp:|^https:)/) == -1)
        throw "Script attempted to add sidebar panel from illegal source";
}

which is the first thing called when you tried to add a sidebar via:

nsSidebar.prototype.addPanelInternal()

which is used by:
 
nsSidebar.prototype.addPanel =
function (aTitle, aContentURL, aCustomizeURL)
{
    debug("addPanel(" + aTitle + ", " + aContentURL + ", " +
          aCustomizeURL + ")");
    
    return this.addPanelInternal(aTitle, aContentURL, aCustomizeURL, false);
}

3- Eventually, users should be able to specify their own sidebars, which might
live on disk, the same way we let people browser to local files via URL bar.

Links loaded from sidebars should be checkloaded (http: sidebars cannot point to
file:), but the sidebar rdf itself should allow file URLs. 

In firefox, the sidebars are stored as bookmarks, and we know bookmarks of file:
is allowed...

Comment 13

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Tony Mechelynck [:tonymec]]

In reply to comment #14: I don't remember voting for this bug and I don't remember using file:/// sidebars. So, un-voting a

Comment 16

[Tony Mechelynck [:tonymec]]

...nd UNCONFIRMing (and somehow hit tab, then spacebar before the comment was finished).

Comment 17

[Phoenix]

WORKSFORME
Local html loads in sidebar fine with code from comment 0
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1