Closed Bug 298478 Opened 19 years ago Closed 19 years ago

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

Categories

(Core :: XUL, defect, P1)

Product:
Core
Component:
XUL
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.8beta3

People

(Reporter: mcsmurf, Assigned: jst)

References

Details

(4 keywords, Whiteboard: branch checkins needed)

Attachments

(3 files)

Make the win/unix hiddenwindow a blank chrome window, rev. 1
3.40 KB, patch
brendan
: superreview+
Details | Diff | Splinter Review
Alternative approach, give the component loader its own compilation context
9.43 KB, patch
shaver
: review+
dveditz
: superreview+
jay
: approval-aviary1.0.5+
jay
: approval1.7.9+
Details | Diff | Splinter Review
Branch patch that was checked in.
8.70 KB, patch
Details | Diff | Splinter Review 
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...
*** Bug 298441 has been marked as a duplicate of this bug. ***
Taking a quick stab in the dark, could this be related to patch for bug 296397 
for regexp access?
Severity: normal → major
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 :)
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).
Flags: blocking1.8b3?
The patch for bug 296397 is in the cvsblame list given in comment 4

Chaning component to JavaScript Engine
Component: XPConnect → JavaScript Engine
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] 
What source lines correspond to those line numbers?

/be
Assignee: dbradley → brendan
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta3
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);
      };
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
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?
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





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
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.
I can confirm the behavior that Ria describes.
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).
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.
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.
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.
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?
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

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
bug 298555 could be related.


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.
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.
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.
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.
Severity: major → critical
Flags: blocking-aviary1.1?
(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
OS: Windows 2000 → All
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.
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?
OS: All → Windows 2000
Wouldn't "XP" be better though? "2000" sorta gives the impression that it
doesn't happen on XP, which it does.
This bug should bite all but Mac, so I'm leaving it set to PC / All.

/be
Severity: critical → major
OS: Windows 2000 → All
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.
Assignee: brendan → benjamin
Flags: blocking1.8b3?
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Component: JavaScript Engine → XP Toolkit/Widgets
Flags: blocking1.8b3+ → blocking1.8b3?
Flags: blocking1.8b3? → blocking1.8b3+
This needs to get onto the branches as well.
Flags: blocking1.7.9+
Flags: blocking-aviary1.0.5+
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
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?
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.
This needs testing on linux or windows, as I'm stuck with mainly mac right now.
Attachment #187142 - Flags: superreview?(brendan)
Attachment #187142 - Flags: review?(mconnor)
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
Ok, the patch fixes (at least) the testcase with Clear Cache/try to download
file afterwards on Windows with Mozilla.
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.
Bug 296397 landed on the branches on 21-June-2005.
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.
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.
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.
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.
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.
(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 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
Attachment #187142 - Flags: superreview?(brendan) → superreview+
*** Bug 298634 has been marked as a duplicate of this bug. ***
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.
Attachment #187169 - Flags: superreview?(brendan)
Attachment #187169 - Flags: review?(shaver)
(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.

*** Bug 298662 has been marked as a duplicate of this bug. ***
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.
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 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
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
dbradley and shaver should weigh in too.

/be
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.


(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?
(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.
(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.
Summary: Downloads fail with "..could not be saved, because the source file could not be read" → 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")
*** Bug 298759 has been marked as a duplicate of this bug. ***
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
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.
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......
*** Bug 298907 has been marked as a duplicate of this bug. ***
(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]
(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)
(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 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.
Attachment #187169 - Flags: review?(shaver) → review+
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.
Blocks: 298860
Attachment #187169 - Flags: superreview?(brendan) → superreview?(dveditz)
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
Attachment #187169 - Flags: approval1.7.9+
Attachment #187169 - Flags: approval-aviary1.0.5+
Comment on attachment 187169 [details] [diff] [review]
Alternative approach, give the component loader its own compilation context

sr=dveditz
Attachment #187169 - Flags: superreview?(dveditz) → superreview+
*** Bug 298999 has been marked as a duplicate of this bug. ***
Severity: major → blocker
Keywords: smoketest
Whiteboard: [cb] ready to land for 1.8b3?
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.
Attachment #187142 - Flags: review?(mconnor)
fix checked in with a=drivers per bsmedberg, respins requested for BFT
day/smoketesting
Assignee: benjamin → jst
Whiteboard: [cb] ready to land for 1.8b3?
Flags: blocking-aviary1.1?
jst, I landed this on trunk for BFT day, I left the branch landings for you
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Whiteboard: branch checkins needed
Flags: blocking-aviary1.1?
bugs.mano@sent.com changed:

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

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

Because it's fixed.
*** Bug 299075 has been marked as a duplicate of this bug. ***
How do I do to apply this patch??? Please.....
Today's build works fine. I think the patch is already applied.
I've install the build 2005062807 to Linux, but appear same error, when download.
This error was not resolved with patch?
(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...
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.
Read Comment 79, it will be fixed on the branches soon now.
Fixed on branches.
Keywords: fixed-aviary1.0.5, fixed1.7.9
*** Bug 299429 has been marked as a duplicate of this bug. ***
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?
Status: RESOLVED → VERIFIED
Please create an explicit dependency on bug # 296397 , as distributor
experienced issue after only applying critical security issues .
Depends on: 296397
*** Bug 298700 has been marked as a duplicate of this bug. ***
*** Bug 323541 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: