206699 - NS_ERROR_FAILURE on line 350 of nsBrowserStatusHandler.js

Status: RESOLVED DUPLICATE of bug 195833

(SeaMonkey :: General, defect)

Description

[Michael Sinz]

The above URL is an simple HTML/JavaScript page that shows this bug (and a few
others related to the same code)

This specific problem is caused when a key (alpha, numeric, symbol, etc) is
pressed.  The "document.onkeydown" callback script takes the event and renders
it into the IFrame for this example.  The rendering is not specifically needed.

However, it seems that the nsIURI.hostPort is either null or invalid but is
assumed to be valid.

The exact JavaScript error is:

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIURI.hostPort]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"
 location: "JS frame :: chrome://navigator/content/nsBrowserStatusHandler.js ::
anonymous :: line 350"  data: no]
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 350

Comment 1

[Michael Sinz]

Note that this seems to happen on both Windows and MacOS-X versions of Mozilla
too.  (Same JavaScript error)

On the Mac version, the key presses do not always come through - it may be
related to the type-ahead find thing?

This happens in the 1.3.1 official builds for these platforms.

Comment 2

[Michael Sinz]

Note that I ran into this due to the keyboard support I added to the WordWiggle
game.  It has not prevented the game from working but it has caused these
JavaScript errors in the JS console and, on the Mac, the in-consistant behavior.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Michael, this has been fixed since 1.3.1.  The fix appears in 1.4b builds, and
will appear in 1.4 final.

Thank you for the excellent bug report, by the way!

*** This bug has been marked as a duplicate of 195833 ***

Comment 4

[Michael Sinz]

Sorry for the duplicate - I was distracted by the typing stuff and did not
notice the fact that it also happens on the button clicks (and thus was related
to wysiwyg: (and other) URI issues.