Closed Bug 253943 Opened 21 years ago Closed 20 years ago

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://192.168.100.75/test/iframe.html :: foo :: line 19" data: no]

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
Other
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: MichalPolak, Unassigned)

Details

Attachments

(1 file)

Example + callstacks + ctx/options fields
282.28 KB, application/octet-stream
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 As requested by timeless@bemail.org (see the bug entry http://bugzilla.mozilla.org/show_bug.cgi?id=252836) I have re-entered this bug. The attachement (id=154658) is availabe through the bug entry http://bugzilla.mozilla.org/show_bug.cgi?id=252836 : http://bugzilla.mozilla.org/attachment.cgi?id=154658&action=view . [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMLocation.href]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://192.168.100.75/test/iframe.html :: foo :: line 19" data: no] (1) This exceptions occurs when when I tried to set the value of location.href property of an iframe - see also the attached file "iframe-remote.html": ... <iframe src="iframe1.html" scrolling="no" name="main" height=460 width=470></iframe> ... frames['main'].location.href="iframe1.html"; ... Note that I am using a non-standard (XPCOM-based) key event generator. A listener to that generator is registered in the onload handler: ... <body onload="stb.remote.addListener(key_handler, stb.remote.REMOTE_EVENT_KEY_DOWN);"> ... (2) Of course, the problem might be with the XPCOM component. However, when I change the code above to: ... main.location.assign("iframe1.html") ... the exception is not thrown out. (3) Finally, I checked if the exception occurs, when the standard onkeypress handler is used within the script ("iframe-keypress.html"). The answer is - no, the code works fine. All these experiments described above made me think that something was bad with the XPCOM components. So, I did some investigation, briefly described below: 1. The reason of the exception is that the field "options" of the context is equal to zero, whearas the function GetScriptContextFromJSContext excepts that the 3rd bit is set (JSOPTION_PRIVATE_IS_NSISUPPORTS): ./dom/public/nsIScriptContext.h: inline nsresult 343 GetScriptContextFromJSContext(JSContext *cx, nsIScriptContext **result) 344 { 345 *result = nsnull; 346 6> 347 if (!(::JS_GetOptions(cx) & JSOPTION_PRIVATE_IS_NSISUPPORTS)) { 348 return NS_ERROR_INVALID_ARG; 349 } 0> 350 351 nsresult rv = NS_OK; 352 353 nsISupports *supports = 354 NS_STATIC_CAST(nsISupports *, ::JS_GetContextPrivate(cx)); 355 356 if (supports) { 357 rv = CallQueryInterface(supports, result); 358 } 359 360 return rv; 361 } The attached picture "callstack1.jpg" shows the callstack for this case. 2. A similar callstack can be observed, when the location is changed by means of the standard "keypress" handler - see the file "callstack2.jpg". In this case, the field "options" of the context is equal to 8 (JSOPTION_PRIVATE_IS_NSISUPPORTS). As a result the function "GetScriptContextFromJSContext()" does not return NS_ERROR_INVALID_ARG, so the exception is not thrown out. 3. Finally, the file "callstack3.jpg" contains the callstack after changing the line: frames['main'].location.href="iframe1.html"; to: main.location.assign("iframe1.html") This callstack is pretty different from those two previous ones. And in this case the code works fine. Thus, I guess that my XPCOM component is written correctly. Have you got any idea what the reason of the exception can be? Thanks in advance for your help. Michal Reproducible: Always Steps to Reproduce:
I checked that the code works fine, when the line: frames['main'].location.href="iframe1.html"; is called from withing a timeout function: setTimeout( function () { frames['main'].location.href="iframe1.html";}, 0); See the file iframe-timeout.html in the attachement. Also, I added two screenshots of the callstack: 1. callstack-timeout.jpg - shows the callstack of the code with the added setTimeout function. Code works fine, the ctx/options field is equal o 8 - see ctx-options-timeout.jpg. 2. callstack-tuimeout.jpg - show the callstacj of the original code (no timout function). The exception is reported, the ctx/options field is euqal to 0 - see ctx-options-error.jpg. Hope this will be of any help for you.
In the bug entry http://bugzilla.mozilla.org/show_bug.cgi?id=191994 a similar temporary workaround is proposed: setTimeout( function() { document.getElementById( 'iframeID' ).contentDocument.designMode = "on"; }, 10 ); Are these two bugs linked to each other? It looks like a problem with iframes...
I have prepared a step-by-step procedure and simplfiled version of the XPCOM components (both the source and binary versions) to enable you to repeat this bug. The binary version is compiled for Linux (i-386+). The archive contains the following folders: http/ - example showing incorrent behaviour of the browser Middleware/ - the stuff implementing XPCOM components Mozilla/ - a part of the browser directory with the new files TestGtkEmbed/ - changes to the TestGtkEmbed* files. To repeat the bug please perform the following steps: 1. Copy the new and modified object file into your Mozilla folder (from the directory "Mozilla" in the archive). 2. Open the sample page "http/iframe/iframe.html" with the browser. 3. Press the key 1 (or 2) which open an iframe. The iframe is not loaded. Note: the XPCOM components emulates a keybaord device. Its aim to send key events to the browser. The archive is available through this URL: http://prograk.com.pl/~michal/MozillaProblem.tgz . Unfortunatelly, this HTTP server does not have too broad link. Anyway, there is no problem to upload the file on any FTP server, if requested (or just email that file). Regards, Michal
Severity: normal → major
I have added timeless@myrealbox.com on the cc list, as I guess it is of some interest for him/her.
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
The bug is still present in Firefox 1.5 Beta2. The error message is: Error: uncaught exception: [Exception... "Component returned failure code: 0x805e000a [nsIDOMLocation.href]" nsresult: "0x805e000a (<unknown>)" location: "JS frame :: http://www.sskduesseldorf.de/javascript/scripte.js :: ladeFrames :: line 17" data: no] URL: http://www.sskduesseldorf.de/ To reproduce the error just click a link in the left table of the site.
I just ran into this bug in our product. We were using a window.open to a relative URL in a hidden frame. This ran into bug #177819. Then we tried accessing that frame directly using the same relative URL. That ran into this bug. Finally the setTimeout workaround mentioned in this bug worked. The error message I got was: Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a [nsIDOMLocation.href]" nsresult: "0x804b000a (<unknown>)" location: "JS frame :: [My company's internal page]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: