298478 - Downloads fail with "..could not be saved, because the source file could not be read" (error in JS Console: "Error: uncaught exception:Permission denied to get property RegExp.constructor")

Status: VERIFIED FIXED

(Core :: XUL, defect, P1)

Description

[Frank Wein [:mcsmurf]]

First: This is NO dupe of Bug 180672.
With current trunk builds, you suddenly (i don't know how to reproduce) get the
error "xyz.bla could not be saved, because the source file could not be read".
At the same time this error occours in JS Console: "Error: uncaught exception:
Permission denied to get property RegExp.constructor" (when clicking a download
link). I also got other errors in JS Console (i think those are related) like
Error: [Exception... "'Permission denied to get property
HTMLDocument.getElementsByTagName' when calling method:
[nsIDOMEventListener::handleEvent]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "<unknown>"  data: no]
I think this a regression since i've never seen this bug happening before like
this, also two other people reported seeing this error (one with a current trunk
build from today, other unknown). Deleting compreg.dat solved this problem.
Maybe this needs to moved somewhere else, i'm not really sure if XPConnect is
the right component for this...

Comment 1

[Frank Wein [:mcsmurf]]

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

Comment 2

[David Bradley]

Taking a quick stab in the dark, could this be related to patch for bug 296397 
for regexp access?

Comment 3

[Frank Wein [:mcsmurf]]

Ok, way to reproduce is:
Clear Cache (observe uncaught exception: [Exception... "Component returned
failure code: 0x80004005 (NS_ERROR_FAILURE) [nsICacheService.evictEntries]" 
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://communicator/content/pref/pref-cache.js :: prefClearCache :: line 68" 
data: no] in JS Console) and restart Mozilla/Firefox. Now the bug occours.
dbradley: Yeah i also suspect that bug caused this, but brendan or someone else
who knows more must comment on this :)

Comment 4

[Peter van der Woude [:Peter6]]

tested regression window

works 20050621 1425 pdt build
fails 20050621 2225 pdt build

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-06-21+13%3A55%3A00&maxdate=2005-06-21+21%3A56%3A00&cvsroot=%2Fcvsroot

Comment 5

[Frank Wein [:mcsmurf]]

If it is not yet clear, you have to click a link to a file to trigger this bug
(like on kernel.org to the top or any file on the ftp.mozilla.org FTP).

Comment 6

[David Bradley]

The patch for bug 296397 is in the cvsblame list given in comment 4

Chaning component to JavaScript Engine

Comment 7

[Jon Stritar]

Someone reported that Forecastfox failed with a similar error message:
Error: uncaught exception: Permission denied to get property RegExp.constructor

Error: [Exception... "Component returned failure code: 0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame ::
file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Mozilla/Firefox/Profiles/dcni7zsx.default/extensions/%7B0538E3E3-7E9B-4d49-8831-A227C80A7AD3%7D/components/nsForecastfox.js
:: anonymous :: line 151" data: no]
Source File:
File:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Mozilla/Firefox/Profiles/dcni7zsx.default/extensions/%7B0538E3E3-7E9B-4d49-8831-A227C80A7AD3%7D/components/nsForecastfox.js
Line: 151

Error: uncaught exception: [Exception... "Component returned failure code:
0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult:
"0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame ::
file:///C:/Documents%20and%20Settings/Administrator/Application%20Data/Mozilla/Firefox/Profiles/dcni7zsx.default/extensions/%7B0538E3E3-7E9B-4d49-8831-A227C80A7AD3%7D/components/nsForecastfox.js
:: anonymous :: line 151" data: no] 

Comment 8

[Brendan Eich [:brendan]]

What source lines correspond to those line numbers?

/be

Comment 9

[Tim Meader]

try {
      //set components
      var pbs =
Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
      var sbs =
Components.classes["@mozilla.org/intl/stringbundle;1"].getService(Components.interfaces.nsIStringBundleService);
LINE 151---->      this._ping =
Components.classes["@ensolis.com/forecastfox/ping;1"].getService(Components.interfaces.ffIPing);
        this._parser =
Components.classes["@ensolis.com/forecastfox/parser;1"].getService(Components.interfaces.ffIParser);
      this._profiles =
Components.classes["@ensolis.com/forecastfox/profiles;1"].getService(Components.interfaces.ffIProfiles);
      this._disk =
Components.classes["@ensolis.com/forecastfox/disk;1"].getService(Components.interfaces.ffIDisk);
      this._obs =
Components.classes["@mozilla.org/observer-service;1"].getService(Components.interfaces.nsIObserverService);
        this._timer =
Components.classes["@mozilla.org/timer;1"].createInstance(Components.interfaces.nsITimer);
      this._branch = pbs.getBranch("forecastfox.");
      this._bundle =
sbs.createBundle("chrome://forecastfox/locale/forecastfox.properties");

      //startup components
      this._disk.start();
      this._ping.start();
      this._parser.start();
      var ps =
Components.classes["@mozilla.org/embedcomp/prompt-service;1"].getService(Components.interfaces.nsIPromptService);
      try {
        var restart = this._profiles.start();
        if (restart.severity != ffIError.SEVERITY_INFO)
          ps.alert(this._getWindow(), restart.description, restart.tooltip);
      } catch(e) {
        ps.alert(this._getWindow(),
this._bundle.GetStringFromName("ff.migrate.label"),
this._bundle.GetStringFromName("ff.migrate.tooltip"));
        this._disk.recordErrorMsg("An error occured while trying to load the
profiles module. Exception details: "+e);
      };

Comment 10

[Brendan Eich [:brendan]]

Where's the RegExp.constructor, or any regexp (literal or constructed) usage, on
that line?

Is the XUL preprocessor messing up line numbers?

Can you find any literal or constructed RegExp usage in that extension's source?
 Please cite all such usage if possible.

/be

Comment 11

[Jon Stritar]

I assume RegExp is referring to regular expressions? We only use them in the
ffParser component, but getService for that is on line 152.. (plus it wouldn't
be created/used at that time). Maybe the actual getService method does something
with  RegExp?

Comment 12

[Jon Stritar]

Actually.. the String.replace method always uses regex's right? In that case
line 180 of ffPing uses a replace:

    var action = aProperty.ValueUTF8.replace(prefix, "");

It is inside a method of an object though.. so I wouldn't think that would be
called. 

http://www.mozdev.org/source/browse/forecastfox/src/components/ffPing.js?rev=1.7&content-type=text/x-cvsweb-markup

Comment 13

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050622
Firefox/1.0+ ID:2005062213

for one or another reason the problem of comment #0 resolved itself.
weirder even, I can't reproduce it anymore with the build i confirmed the bug with

Comment 14

[Ria Klaassen (not reading all bugmail)]

When I enable or disable an extension (no matter what extension), Forecastfox
will work and this error-bug will not show up.
When I restart Firefox without enabling or disabling an extension, Forecastfox
will not show up and I get also an error when clicking on for instance this
link: http://www.mdformulations.nl/new2/doc/klst005.doc
I tried it 5 times.

Comment 15

[Tim Meader]

I can confirm the behavior that Ria describes.

Comment 16

[PikeUK]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050622
Firefox/1.0+
No extensions/themes installed.

The quicksearch box on the BMO front page gives the following two errors in the
 console when the Show button is clicked:

Error: uncaught exception: Permission denied to get property RegExp.constructor

Error: uncaught exception: [Exception... "Factory not registered"  nsresult:
"0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  location: "JS frame ::
https://bugzilla.mozilla.org/quicksearch.js :: go_to :: line 53"  data: no]

This occured on another machine earlier today but I can no longer reproduce it
there (I had temporarily reverted to an older build before reinstalling today's
build).

Comment 17

[Ria Klaassen (not reading all bugmail)]

On a very new profile (first run) I get no error but a download window.
The error seems to occur on second and next start with the same profile.

Comment 18

[Ria Klaassen (not reading all bugmail)]

Talking about the new profile without extensions:
When I remove everytime the file "extensions.ini" out of the profile, the error
seems not to occur.
When I restart Firefox without removing this file, I get the error.

Comment 19

[Bob Clary [:bc] (inactive)]

The full error in a debug build is:
JS Component Loader: ERROR (null):0
                     uncaught exception: Permission denied to get property
RegExp.constructor 

I can reproduce this with a stack to the printf, if you want to see it.

Comment 20

[Johnny Stenback (:jst)]

The case I've looked into so far is what happens when this error is triggerd
from the Forecastfox extension. With it, we get the exception while compiling
the script for a JS component. That compilation happens on the safe context, and
the principal we're compiling for is the system principal. But while compiling,
we end up looking up RegExp.constructor and that throws the exception. The
reason is that we don't find any principals in the running code (in the JS stack
frames on the safe context), there are two frames, neither of which have a
function object or a script, so we end up getting the principal from the global
object in the context we're compiling in, and that, beeing the safe context,
gets us the about:blank principal.

Shaver and I looked this over a bit and our thinking from short investigation
was that we probably need to make the compilation code push a stack frame before
compiling to carry the principals we're compiling for (in an empty script object
or whatever). That way we'd find the right principals while compiling and we
wouldn't get security exceptions while compiling scripts. Or maybe we could even
have a special stack frame flag that'd tell the caps code that we're compiling
code and it wouldn't throw exceptions at us...

Thoughts?

Comment 21

[Johnny Stenback (:jst)]

Stack where the error is thrown:

nsScriptSecurityManager::CheckObjectAccess(JSContext * cx=0x01a45a20, JSObject *
obj=0x028c76d0, long id=0x00b7350c, JSAccessMode mode=JSACC_READ, long *
vp=0x0012bd18) Line 456 + 0x2e
js_CheckAccess(JSContext * cx=0x01a45a20, JSObject * obj=0x028c76d0, long
id=0x00b76b38, JSAccessMode mode=JSACC_READ, long * vp=0x0012bd18, unsigned int
* attrsp=0x0012bc40) Line 3449 + 0x4c
CheckCtorGetAccess(JSContext * cx=0x01a45a20, JSObject * obj=0x028c76d0, long
id=0x00b7350c, long * vp=0x0012bd18) Line 3710 + 0x21
js_GetProperty(JSContext * cx=0x01a45a20, JSObject * obj=0x028c76d0, long
id=0x00b76b38, long * vp=0x0012bd18) Line 2808 + 0xf8
JS_GetConstructor(JSContext * cx=0x01a45a20, JSObject * proto=0x028c76d0) Line
2222 + 0x24
js_InitRegExpClass(JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220) Line
3767 + 0x13
JS_ResolveStandardClass(JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220,
long id=0x00b734bc, int * resolved=0x0012bd80) Line 1427 + 0xb
BackstagePass::NewResolve(nsIXPConnectWrappedNative * wrapper=0x0300d490,
JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220, long id=0x00b734bc,
unsigned int flags=0x00000010, JSObject * * objp=0x0012be8c, int *
_retval=0x0012be08) Line 71 + 0x16
XPC_WN_Helper_NewResolve(JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220,
long idval=0x00b734bc, unsigned int flags=0x00000010, JSObject * *
objp=0x0012bf0c) Line 967 + 0x45
js_LookupPropertyWithFlags(JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220,
long id=0x00b764b0, unsigned int flags=0x00000010, JSObject * * objp=0x0012bf60,
JSProperty * * propp=0x0012bf54) Line 2545 + 0x4c
js_FindConstructor(JSContext * cx=0x01a45a20, JSObject * start=0x00000000, const
char * name=0x100d20c8, long * vp=0x0012bf90) Line 1959 + 0x1b
GetClassPrototype(JSContext * cx=0x01a45a20, JSObject * scope=0x00000000, const
char * name=0x100d20c8, JSObject * * protop=0x0012bff4) Line 3671 + 0x15
js_NewObject(JSContext * cx=0x01a45a20, JSClass * clasp=0x1010ba28, JSObject *
proto=0x00000000, JSObject * parent=0x00000000) Line 1839 + 0x17
js_NewRegExpObject(JSContext * cx=0x01a45a20, JSTokenStream * ts=0x03008bb0,
unsigned short * chars=0x03008eb0, unsigned int length=0x0000000c, unsigned int
flags=0x00000002) Line 3802 + 0x12
js_GetToken(JSContext * cx=0x01a45a20, JSTokenStream * ts=0x03008bb0) Line 1873
+ 0x33
js_MatchToken(JSContext * cx=0x01a45a20, JSTokenStream * ts=0x03008bb0,
JSTokenType tt=TOK_RP) Line 2031 + 0xd
[...]
Statements(JSContext * cx=0x01a45a20, JSTokenStream * ts=0x03008bb0,
JSTreeContext * tc=0x0012cfe0) Line 1025 + 0x11
js_CompileTokenStream(JSContext * cx=0x01a45a20, JSObject * chain=0x028c7220,
JSTokenStream * ts=0x03008bb0, JSCodeGenerator * cg=0x0012cfe0) Line 468 + 0x11
CompileTokenStream(JSContext * cx=0x01a45a20, JSObject * obj=0x028c7220,
JSTokenStream * ts=0x03008bb0, void * tempMark=0x01a45a68, int *
eofp=0x00000000) Line 3336 + 0x1a
JS_CompileFileHandleForPrincipals(JSContext * cx=0x01a45a20, JSObject *
obj=0x028c7220, const char * filename=0x0318f600, _iobuf * file=0x1027c898,
JSPrincipals * principals=0x00b9493c) Line 3518 + 0x17
mozJSComponentLoader::GlobalForLocation(const char * aLocation=0x00afb6b8,
nsIFile * component=0x03129750) Line 1054 + 0x2a
mozJSComponentLoader::ModuleForLocation(const char *
registryLocation=0x00afb6b8, nsIFile * component=0x00000000) Line 837 + 0x13
mozJSComponentLoader::GetFactory(const nsID & aCID={...}, const char *
aLocation=0x00afb6b8, const char * aType=0x00af90b8, nsIFactory * *
_retval=0x0012d320) Line 384 + 0xe
nsFactoryEntry::GetFactory(nsIFactory * * aFactory=0x0012d320,
nsComponentManagerImpl * mgr=0x003ebaf0) Line 302 + 0x3a
nsComponentManagerImpl::CreateInstance(const nsID & aClass={...}, nsISupports *
aDelegate=0x00000000, const nsID & aIID={...}, void * * aResult=0x0012d3d0) Line
1906 + 0x10
nsJSCID::CreateInstance(nsISupports * * _retval=0x0012d53c) Line 809 + 0x4a
XPTC_InvokeByIndex(nsISupports * that=0x0303d000, unsigned int
methodIndex=0x0000000a, unsigned int paramCount=0x00000001, nsXPTCVariant *
params=0x0012d53c) Line 102
XPCWrappedNative::CallMethod(XPCCallContext & ccx={...},
XPCWrappedNative::CallMode mode=CALL_METHOD) Line 2105 + 0x1e
XPC_WN_CallMethod(JSContext * cx=0x0283f790, JSObject * obj=0x028972c0, unsigned
int argc=0x00000001, long * argv=0x0312212c, long * vp=0x0012d810) Line 1348 + 0xe
js_Invoke(JSContext * cx=0x0283f790, unsigned int argc=0x00000001, unsigned int
flags=0x00000000) Line 1178 + 0x20
js_Interpret(JSContext * cx=0x0283f790, unsigned char * pc=0x031c94a7, long *
result=0x0012e2fc) Line 3468 + 0xf
js_Invoke(JSContext * cx=0x0283f790, unsigned int argc=0x00000001, unsigned int
flags=0x00000002) Line 1198 + 0x13
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x031c2f68, unsigned
short methodIndex=0x000b, const nsXPTMethodInfo * info=0x031c1f30,
nsXPTCMiniVariant * nativeParams=0x0012e618) Line 1339 + 0x14
nsXPCWrappedJS::CallMethod(unsigned short methodIndex=0x000b, const
nsXPTMethodInfo * info=0x031c1f30, nsXPTCMiniVariant * params=0x0012e618) Line 462
PrepareAndDispatch(nsXPTCStubBase * self=0x031c2f68, unsigned int
methodIndex=0x0000000b, unsigned int * args=0x0012e6e0, unsigned int *
stackBytesToPop=0x0012e6d0) Line 117 + 0x1c
SharedStub() Line 147
XPTC_InvokeByIndex(nsISupports * that=0x031c2f68, unsigned int
methodIndex=0x0000000b, unsigned int paramCount=0x00000001, nsXPTCVariant *
params=0x0012e820) Line 102
XPCWrappedNative::CallMethod(XPCCallContext & ccx={...},
XPCWrappedNative::CallMode mode=CALL_METHOD) Line 2105 + 0x1e
XPC_WN_CallMethod(JSContext * cx=0x0283f790, JSObject * obj=0x0294b118, unsigned
int argc=0x00000001, long * argv=0x0312204c, long * vp=0x0012eaf4) Line 1348 + 0xe
js_Invoke(JSContext * cx=0x0283f790, unsigned int argc=0x00000001, unsigned int
flags=0x00000000) Line 1178 + 0x20
js_Interpret(JSContext * cx=0x0283f790, unsigned char * pc=0x03014d5b, long *
result=0x0012f508) Line 3468 + 0xf
js_Execute(JSContext * cx=0x0283f790, JSObject * chain=0x01b38580, JSScript *
script=0x03014d20, JSStackFrame * down=0x00000000, unsigned int
flags=0x00000000, long * result=0x0012f610) Line 1408 + 0x13
JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x0283f790, JSObject *
obj=0x01b38580, JSPrincipals * principals=0x00b9493c, const unsigned short *
chars=0x02b54aa8, unsigned int length=0x00000022, const char *
filename=0x031bbad0, unsigned int lineno=0x00000068, long * rval=0x0012f610)
Line 3855 + 0x19
nsJSContext::EvaluateString(const nsAString & aScript={...}, void *
aScopeObject=0x01b38580, nsIPrincipal * aPrincipal=0x00b94938, const char *
aURL=0x031bbad0, unsigned int aLineNo=0x00000068, const char *
aVersion=0x100d284c, nsAString * aRetValue=0x00000000, int *
aIsUndefined=0x0012f6b4) Line 1075 + 0x43
nsGlobalWindow::RunTimeout(nsTimeout * aTimeout=0x030c2130) Line 5239 + 0x6c

Comment 22

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Bug 297536 could be related.

Comment 23

[Brendan Eich [:brendan]]

We shouldn't hack things around this case if it's just a bug.  I mean, if the
safe context is for the hidden window only, and code compiled on the safe
context should always be trusted, then the hidden window should have the system
principal.  If that's too scary because we also use the hidden window for some
other purpose than precompilation, then we need a different context/window.

/be

Comment 24

[Peter van der Woude [:Peter6]]

bug 298555 could be related.

Comment 25

[Max Powers]

This is not Windows specific. Bug also lies under Linux, however there is no
error, clicking on a link using the right mouse button, simply does nothing.
Workaround works.

Comment 26

[Tim Meader]

There's a problem with that workaround though. That works fine for actual links,
but some pages use a javascript triggering system, like a button that says
"Click Here to Begin Download". In those cases right clicking and "save link as"
doesn't work unfortunately. IGN has several pages like that I believe.

Comment 27

[Matt Philmon]

I think this should be raised to "Blocker". The work-around works on some pages
certainly, but there are MANY MANY MANY pages where it doesn't. Not being able
to download files via a web browser is definitely a show-stopping bug.

Comment 28

[Tim Meader]

Raising to critical for the time being to get on the radar. I think this is
warranted since the workaround is clearly not universal. Nominating for blocker
for Firefox as well.

Comment 29

[Thomas K. (:tom)]

(In reply to comment #25)
> This is not Windows specific. Bug also lies under Linux, however there is no
> error, clicking on a link using the right mouse button, simply does nothing.
> Workaround works.

setting os from win2k (i'm on winxp and this happens here...) to all

Comment 30

[Tim Meader]

This is defintely affecting other extensions it seems. Gmail Notifier (which 
two days ago stopped working due to a URL change by Google), for which I'm 
running the fixed 0.4.3 version, has stopped working as of yesterday it seems. 
It is no longer able to login successfully to Gmail. If you start Firefox 
(currently running the Win32 20050623 build) with ONLY Gmail Notifier enabled, 
it throws the RegExp error that is mentioned in this bug. There are no further 
JSConsole messages in this extension's case unfortunately though.

Comment 31

[Benjamin Smedberg]

If this is really about the hidden window principal, then this bug should not be
reproducable on mac, since mac uses a chrome window for the hidden window,
unlike win/unix which use about:blank. Is there a good reason we couldn't use a
chrome version of about:blank for the win/unix hidden window?

Comment 32

[Tim Meader]

Wouldn't "XP" be better though? "2000" sorta gives the impression that it
doesn't happen on XP, which it does.

Comment 33

[Brendan Eich [:brendan]]

This bug should bite all but Mac, so I'm leaving it set to PC / All.

/be

Comment 34

[Tim Meader]

Well, at least on 10.3.9, I can confirm that it does work fine on the Mac. I
just installed the latest Cadence machine build, 20050623 around 9AM, and
installed Forecastfox and GMail Notifier only. Both work fine, and no JSConsole
errors.

Comment 35

[Jay Patel [:jay]]

This needs to get onto the branches as well.

Comment 36

[Ria Klaassen (not reading all bugmail)]

I don't know if this is relevant information, but when I empty or delete the
extensions folder in the program directory and there are no extensions in the
profile, I get only errors when trying to leftclick-download. When I delete the
extensions.ini this has no effect.
Workaround (for one browser-session) is to install an extension.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050623
Firefox/1.0+ ID:2005062305

Comment 37

[Tim Meader]

Jay, is it affecting the branches at all though? Is it wise to make a big code
change (even though it might technically be broken on the branch as well) when
the RegExp error isn't showing up in the current branch? I would think, since
everything is currently working on the branch (links, Forecastfox, GM Notifier)
that this should really only be the focus of Firefox 1.1. Am I wrong about that?

Comment 38

[Tim Meader]

Expanding on comment #36: if you merely disable an extension then restart, it
seems to fix it for that new session (at least initially). You can get
Forcastfox to show up properly, as well as have GM Notifier login properly by
doing this. Links don't work though. Upon the next restart, the problem
resurfaces though.

Comment 39

[Benjamin Smedberg]

Attachment: Make the win/unix hiddenwindow a blank chrome window, rev. 1

This needs testing on linux or windows, as I'm stuck with mainly mac right now.

Comment 40

[Brendan Eich [:brendan]]

The patch for bug 296397 landed on the branches, and that's the culprit for this
trunk regression.  If it didn't have the same effect on the branches, we need to
understand what's different.  But if the branches, as my memory tells me, have
the same hidden window / safe content architecture, and the same principal
associated with the hidden window, then they'll need the fix for this bug too.

/be

Comment 41

[Frank Wein [:mcsmurf]]

Ok, the patch fixes (at least) the testcase with Clear Cache/try to download
file afterwards on Windows with Mozilla.

Comment 42

[Tim Meader]

Benjamin, since we can't view the details of the bug you mentioned, when exactly
was that patch checked in? Since I'm doubtful that many download the nightly
branch releases for testing purposes, perhaps it is happening, and just no one's
downloaded it yet to try. I'm running the Release Candidate of 1.0.5 at home
(the one that asa linked to), and like I said, it's not showing any of these
problems. Would the patch have gone in before or after that? Thanks.

Comment 43

[Benjamin Smedberg]

Bug 296397 landed on the branches on 21-June-2005.

Comment 44

[Tim Meader]

Hmmm, yeah, the build id I have at home says 20050621. But if it landed on June
21st, I guess it wouldn't be in until the 22nd build. I'll try that later and
let you know.

Comment 45

[Thomas K. (:tom)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.9) Gecko/20050623
Firefox/1.0.5

Downloaded a file fine.  Have a few extensions installed though, but the same
thing that failed at home (i'm not upgrading trunk until this is fixed here at
work), the link to dl the new firefox trunk in my bookmarks toolbar, works on 1.0.5

The file I downloaded successfully here and not on newer trunk builds:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/pacifica-trunk/firefox-1.0+.en-US.win32.installer.exe

Looks like it's fine for aviary 1.0.1 branch.

Comment 46

[u52928]

Using Win 98SE. Have both 1.0.5 (tinderbox from 23 June) and tinderbox
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+ .
Both are zip versions / both are running from the same old 1.0.4 profile I've
been using for 10 days or so.

This is reproducible every time: Unzip FF trunk over existing version, can't
download as per bug description. 

Erase the existing FF folder and unzip into "new" folder, download works fine
indefinitely; can download anything as many times as desired.

Close and re-start program; download problem as described.

Comment 47

[Tim Meader]

Can confirm now on the aviary branch as well. Just downloaded the 20050623
branch tinderbox exe. After install, on the first startup of Firefox, everything
works fine. After that though, every other restart, GM Notifier isn't working,
nor is Forecastfox, and clicking the link in comment #45 (while not producing a
pop-up error message as it does on the trunk) does not work. It just says the
"Transferring data" message in the status bar, but nothing happens. If you look
at the JSConsole though, the same RegExp error has been thrown.

Jay, my apologies for jumping the gun.

Comment 48

[Frank Wein [:mcsmurf]]

tmeader: Can you please stop commenting here if you don't have anything useful
to say (some comments are useful but most are not)? This is like the 16th
comment on you, please summarize your comments more or don't comment.

Comment 49

[Thomas K. (:tom)]

(In reply to comment #47)
> and clicking the link in comment #45 (while not producing a
> pop-up error message as it does on the trunk) does not work. It just says the
> "Transferring data" message in the status bar, but nothing happens.

Yep, that happens now.  I installed over a previous 1.0.4 tinderbox build, and
it worked the first time, and now doesn't.  I clicked the link in the toolbar
just like before, too.  Interesting, so it does happen on 1.0.5.  Blocker it is.

Comment 50

[Brendan Eich [:brendan]]

Comment on attachment 187142 [details] [diff] [review]
Make the win/unix hiddenwindow a blank chrome window, rev. 1

sr=me provided there are no Ts regressions on sensitive platforms (ones with
sucky filesystem i/o).

/be

Comment 51

[:Gavin Sharp [email: [e-mail]]]

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

Comment 52

[Johnny Stenback (:jst)]

Attachment: Alternative approach, give the component loader its own compilation context

This seems like a safer approach here, it doesn't change the safe context's
principal (which sort of scares me), but in stead gives the component loader
its own compilation context that it uses for compiling code, and that gives the
compiled code the right principals and we don't get this exception any more.

Comment 53

[bugzilla]

(In reply to comment #39)
> Created an attachment (id=187142) [edit]
> Make the win/unix hiddenwindow a blank chrome window, rev. 1
> 
> This needs testing on linux or windows, as I'm stuck with mainly mac right now.

This patch fixes the problem on linux.

Comment 54

[Kevin Brosnan]

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

Comment 55

[Nathan]

Since the bug seems to have as much effects on both DOWNLOADING and xtension
icons disapearing, I think both should be written in the "summary" for the bug.
It took me time to understand that both the bugs were the same.

Comment 56

[Benjamin Smedberg]

jst: I'm not sure why we're worried about the hiddenwindow principal,
considering that on mac the hiddenwindow already has chrome privileges. I like
the idea of keeping the js componentloader script context entirely within
xpconnect, but at least to my eyes it seems like a significantly more
regression-prone solution.

Comment 57

[Brendan Eich [:brendan]]

I don't think jst's patch is regression-prone.  It's arguably safer for
xpconnect to roll its own context, than to conserve/reuse the hidden window in a
fit of frugality (I was involved).  It looks like jst's patch also reduces
codesighs.

/be

Comment 58

[Brendan Eich [:brendan]]

I should add that maybe we want Benjamin's patch too, for cross-platform
consistency.  Given that patch, we don't require jst's, but jst's makes
xpconnect not depend on the principal of a window object whose context it is
apprised of as a "safe context" -- which turned out to be a bum steer, as this
bug demonstrates.

I'm in favor of decoupling xpconnect here, making it fend for itself better. 
Benjamin, what do you say?

/be

Comment 59

[Brendan Eich [:brendan]]

dbradley and shaver should weigh in too.

/be

Comment 60

[David Bradley]

Maybe an option would be to apply Benjamin's patch to the branches, and apply 
both to the trunk.

From what I saw of jst's patch there doesn't appear to be a great risk, but 
it's not a trivial change. Someone who knows the state of the branches and how 
risk adverse a branch is should make that call.

Comment 61

[Johnny Stenback (:jst)]

(In reply to comment #56)
> jst: I'm not sure why we're worried about the hiddenwindow principal,
> considering that on mac the hiddenwindow already has chrome privileges. I like
> the idea of keeping the js componentloader script context entirely within
> xpconnect, but at least to my eyes it seems like a significantly more
> regression-prone solution.

I didn't know the Mac's hidden window already had chrome privs. That scares me
becuase the hidden window's context is what's used to execute JS when no other
context is avaliable, as in when executing event handlers registered with
addEventListener() or other callback functions where we're dealing with wrapped
JS objects and no context is available through wich we find the JS context where
the code came from. Given that, it seems possible that there are cases where
we'd be running untrusted code in a context with chrome privs, which in and of
itself should be fine, but if there are other bugs that leads to caps getting
the privs from the context (as happens in this case), we'd be giving untrusted
script chrome privs.

Why does the Mac's hidden window have chrome privs?

Comment 62

[bugzilla]

(In reply to comment #52)
> Created an attachment (id=187169) [edit]
> Alternative approach, give the component loader its own compilation context
> 
> This seems like a safer approach here, it doesn't change the safe context's
> principal (which sort of scares me), but in stead gives the component loader
> its own compilation context that it uses for compiling code, and that gives the
> compiled code the right principals and we don't get this exception any more.

I can confirm this patch works on linux.

Comment 63

[OstGote!]

(In reply to comment #35)
> This needs to get onto the branches as well.

Right, this affects also Mozilla 1.7 branch. I've just installed  Mozilla 1.7.9
build 2005062406 on WinXP and got the errors from comment 0 (first two errors).
Because I know Bug 180672 I deleted compreg.dat and this helped me immediately.
Build 2005062107 worked as expected. Expanding summary.

Comment 64

[Andrew Schultz]

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

Comment 65

[Benjamin Smedberg]

The mac hidden window is used to form the menu that is displayed to the user
when there are no other windows open on mac. See
http://lxr.mozilla.org/mozilla/source/xpfe/appshell/src/nsAppShellService.cpp#157

Comment 66

[Benjamin Smedberg]

I'm definitely in favor of decoupling xpconnect, by the way; I was just
concerned about the branch-worthiness of that decoupling. But if it's safer than
handing out chrome privs, let's go for it.

Comment 67

[Caleb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050626
Firefox/1.0+ ID:2005062621

This seems to WFM now......

Comment 68

[Carsten Book [:Tomcat]]

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

Comment 69

[Caleb]

(In reply to comment #67)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050626
> Firefox/1.0+ ID:2005062621
> 
> This seems to WFM now......

Actually, in this build I have now the Gmail Notifier extension started working,
and so did the file downloads.

But after pressing the Clear Cache button in the preferences I get this in the
JS Console:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsICacheService.evictEntries]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/sanitize.js :: anonymous :: line 40"  data: no]

Comment 70

[Oliver Saier]

(In reply to comment #67)
> This seems to WFM now......
Yes but when I click cancel I get 3:
Error: dialog has no properties
Source File: chrome://mozapps/content/downloads/unknownContentType.xul
Line: 1
(Pacifica 2005062705)

Comment 71

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #70)
> Yes but when I click cancel I get 3:
> Error: dialog has no properties

That would be bug 294827. Until these patches are landed there isn't much point
in testing this any further.

Comment 72

[Mike Shaver (:shaver emeritus)]

Comment on attachment 187169 [details] [diff] [review]
Alternative approach, give the component loader its own compilation context

r=shaver.  I think this is the right thing for the branch as well: it's easier
to analyze the effects of the changes, and the failure modes worry me less than
with granting more privileges to more windows.

Comment 73

[Scott MacGregor]

I'm pretty sure this bug fix will also fix Bug 298860 where you can't open
attachments in e-mail messages for thundebird right now. 

Comment 74

[Jay Patel [:jay]]

Comment on attachment 187169 [details] [diff] [review]
Alternative approach, give the component loader its own compilation context

a=jay for the branches, pending the final sr= from dveditz

Comment 75

[Daniel Veditz [:dveditz]]

Comment on attachment 187169 [details] [diff] [review]
Alternative approach, give the component loader its own compilation context

sr=dveditz

Comment 76

[Carsten Book [:Tomcat]]

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

Comment 77

[Mike Connor [:mconnor]]

Comment on attachment 187142 [details] [diff] [review]
Make the win/unix hiddenwindow a blank chrome window, rev. 1

Seems consensus is to go the other way, though jst's concerns about the Mac
hidden window should maybe be addressed in a followup bug.

Comment 78

[Mike Connor [:mconnor]]

fix checked in with a=drivers per bsmedberg, respins requested for BFT
day/smoketesting

Comment 79

[Mike Connor [:mconnor]]

jst, I landed this on trunk for BFT day, I left the branch landings for you

Comment 80

[Christian Stadler]

[e-mail] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Flag|blocking-aviary1.1?         |

^^^^^^^^
Why? And why isn't it just minused?

Comment 81

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #80)
> Why? And why isn't it just minused?

Because it's fixed.

Comment 82

[Carsten Book [:Tomcat]]

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

Comment 83

[Clovis Tristao]

How do I do to apply this patch??? Please.....

Comment 84

[Alexey N. Solofnenko]

Today's build works fine. I think the patch is already applied.

Comment 85

[Clovis Tristao]

I've install the build 2005062807 to Linux, but appear same error, when download.
This error was not resolved with patch?

Comment 86

[Tuukka Tolvanen (sp3000)]

(In reply to comment #85)
> I've install the build 2005062807 to Linux, but appear same error, when 

       Compare your build id 2005 06 28 07 with
the timestamp on comment 78. 2005-06-28 08:52 PDT...

Comment 87

[Hussam Al-Tayeb]

I'm terribly sorry for spamming, I'm using the branch 1.0.5 nughlties.
When will this fix go into the branch as I still see it.

Comment 88

[Frank Wein [:mcsmurf]]

Read Comment 79, it will be fixed on the branches soon now.

Comment 89

[Johnny Stenback (:jst)]

Attachment: Branch patch that was checked in.

Comment 90

[Johnny Stenback (:jst)]

Fixed on branches.

Comment 91

[Stephen Donner [:stephend] Not actively reading bugmail]

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

Comment 92

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.8b2) Gecko/20050702 on Windows XP Seamonkey trunk.

Note that bug 180672 still exists in the wild, and isn't this bug...

This is a trunk verification only.

jst: shouldn't we remove 'branch checkins needed' due to you landing on branches
in comment 90?

Comment 93

[Lloyd D Budd]

Please create an explicit dependency on bug # 296397 , as distributor
experienced issue after only applying critical security issues .

Comment 94

[:Gavin Sharp [email: [e-mail]]]

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

Comment 95

[Ria Klaassen (not reading all bugmail)]

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