Closed Bug 9431 Opened 26 years ago Closed 26 years ago

location control field not accepting input, throws JS error

Categories

(SeaMonkey :: UI Design, defect, P1)

Product:
SeaMonkey
Component:
UI Design
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: cmaximus, Assigned: waterson)

References

Details

(Whiteboard: fix in hand)

*summary JavaScript error: Call to nsXPCScriptable failed URL: file:///D|/claudius/Desktop/Seamonkey/1999070808/x86rel/res/samples/navigat or.xul LineNo: 648
ummm somehow that bug fired off before I was done........as i was saying: *summary Typing URI's into the location field is currently fruitless. When you press enter all you get is the (above) Javascipt Error. *Builds ALL platforms as of the 1999070808 builds. Tested on WinNT,Linux, and MacOS *To Repro Simply launch apprunner and type a URI in the location field, press enter. *Expected Apprunner should of course accept the input and proceed to load the specified location *Actual Nothing happens visually in the browser and a JS error is reported to the console
Assignee: trudelle → don
not our widget, over to don for triage.
Assignee: don → radha
Component: XUL → XPApps
Priority: P3 → P1
Target Milestone: M8
Radha, can you figure out what's going on here?
*** Bug 9452 has been marked as a duplicate of this bug. ***
It is not happening in today's pull of the code. I'm assuming this is gone. I'll hold on to this until tomorrow and close it then.
I am still seeing this in 070818 Windows build with same error. Note: workaround is to use File - Open File or Location menu item which works correctly.
*** Bug 9485 has been marked as a duplicate of this bug. ***
Win95 running 1999-07-09-08-M8 build. Still happening.
BTW, in today's build the JS error in navigator.xul occurs on line 657. Otherwise, its the same message.
have we confirmed the two are connected? have we confirmed that "all" folks running debug builds are ok, and all folks running release builds are still broken? there are several navigator xul's in the tree so I'm non sure which one gets packaged and we might be expecting to use. could this be the mix up? matt, pinkerton, danm, hyatt, law, others might have comment. I think we really need to get to the bottom of this in m8. http://cvs-mirror.mozilla.org/webtools/bonsai/cvsblame.cgi?file=mozilla/xpfe/bro wser/src/navigator.xul 655 evaughan 1.47 <toolbox> 656 danm 1.109 <toolbar class="main-bar" chromeclass="toolbar"> 657 pinkerton 1.152 <titledbutton id="back-button" align="bottom" value="&backButton.label;" onclick="BrowserBack()"> 658 radha 1.78 <observes element="canGoBack" attribute="disabled" onChange="BrowserSetBack()"/> 659 pinkerton 1.9 </titledbutton> 660 661 pinkerton 1.152 <titledbutton id="forward-button" align="bottom" value="&forwardButton.label;" 662 pinkerton 1.9 onclick="BrowserForward()"> 663 radha 1.78 <observes element="canGoForward" attribute="disabled" onChange="BrowserSetForward()"/> 664 pinkerton 1.9 </titledbutton> 665 666 hyatt 1.154 <!-- Right now only regular reload is supported. 667 When the functionality is available, look for 668 'Shift' key pressed state and pass on appropriate 669 reload type. (The shift functionality is available. There's a shiftDown field 670 in the event object.) --> 671 matt 1.107 <titledbutton id="reload-button" align="bottom" value="&reloadButton.label;" 672 radha 1.144 onclick="BrowserReallyReload(0)"> 673 <observes element="canReload" attribute="disabled" onChange="BrowserSetReload()" /> 674 pinkerton 1.9 </titledbutton> 675 676 matt 1.107 <titledbutton id="stop-button" align="bottom" value="&stopButton.label;" 677 law 1.96 onclick="BrowserStop()"> 678 <observes element="canStop" attribute="disabled" onchange="BrowserCanStop()"/> 679 pinkerton 1.9 </titledbutton> 680 hyatt 1.5 681 evaughan 1.47 <box align="vertical" flex="100%"> 682 <spring flex="100%"/> 683 radha 1.132 <html:input id="urlbar" type="text" chromeclass="location" style="min-width: 100px; min-height: 25px; height: 20px" 684 hyatt 1.34 onkeyup="if (event.which == 13) { BrowserLoadURL(); }"/> 685 evaughan 1.47 <spring flex="100%"/> 686 </box> 687 rjc 1.114 688 hyatt 1.128 <titledbutton id="translate-button" popup="translationlist" popupanchor="bottomleft" value="&translateButton.label;" align="bottom"> 689 rjc 1.114 </titledbutton> 690 691 matt 1.107 <titledbutton id="print-button" align="bottom" value="&printButton.label;" 692 radha 1.108 onclick="BrowserPrint()"> 693 hyatt 1.20 <observes element="canPrint" attribute="disabled"/> 694 </titledbutton> 695 evaughan 1.47 696 hyatt 1.154 <titledbutton id="Throbber" onclick="window.content.location.href='&throbber.url;'"> 697 law 1.25 <observes element="Browser:Throbber" attribute="busy"/> 698 </titledbutton> 699 evaughan 1.47 </toolbar>
i was just touching titledbutton attributes. don't think i have anything to do with this. what is the JS error? I don't actually see it in the bug anywhere? It might be a problem with navigator.js, depending on what it is.
I'm not seeing this in my (days old) Win32 build. But I can make suggestions on how to debug it... The JS error is almost certainly coming from WrappedNative_Call at: http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcwrappednativejsops .cpp#469 As best I can figure it is calling either CIDGetServiceScriptable::Call at http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#520 or CIDCreateInstanceScriptable::Call at http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#300. Whichever one is returner a non NS_OK result code. There are a few places in each of those functions where this could happen. I suggest setting breakpoints at each of those places to see what is happening. The bigger picture is that somewhere in the xul (or more likely included .js) there is a line of the form "Components.classes.some_prog_id.getService()" or "Components.classes.some_prog_id.createInstance()" where either: 1) "some_progid" does not reference a valid progid; i.e. a typo, or 2) the resultant call to the serivce manager or components manager is failing. number "1" seems more likely to me. Someone might spend a little time looking more closely at the progid strings being used in the xul of js in question. There are some things that will make this easier to fix or avoid in the future... 1) The JS error points you at a particular line in navigator.xul. The bug report (as I start writing this) does not suggest that anyone looked at that line to see what it says. The line and filename information *might* actually be correct. There is/was a bug on joki or vidur's list that JS errors were being reported on the wrong line number and or filename. The JS engine just passes through what the parser of the embeding program said in terms of where the JS source came from. This has to be fixed if it is still broken. We're *never* going to be able to debug JavaScript problems if the line number and filename information is wrong. 2) I need to fix this case where my code is producing a JS error instead of throwing a JS exception. Most of my code is so converted. I missed this 'Call' case. It wouldn't help much here. But in general, calls to native xpcom objects from JavaScript really do sometimes fail and the JS code we write should have try/catch blocks to detect and deal with those conditions. Not doing so would be like writing C++ xpcom code that never checked the nsresult of any method call. 3) I'm working on code that will make it easiler to debug JS problems when debugging C++ code. It will let us do a JS call stack dump in our debugging code or when called by the debugger (for those debuggers that support that). That way we can at least see what JS code was exectuting when we run into a problem in the C++ code. Hope this helps.
THe JS filename/lineno bug that I mentioned (though can't find) is that when there is an error in .js files included from .xul the error is reported as if it were in the .xul rather than the .js file. So, you might want to look at the given line number (or nearby) in an included .js file (navigator.js?) rather than navigator.xul itself.
The error says navigator.xul, but it actually is in navigator.js. The code segment where the error is happening is below. jband had replied to a message in n.p.m.unix reporting this same error yesterday. I have already contacted him. The problem is either not finding the "bookmarks-service" component or XpConnect is not getting inited (as per jband). cc'ing jband & waterson 655 656 waterson 1.22 // rjc: added support for URL shortcuts (3/30/1999) 657 try { 658 var bmks = Components.classes["component://netscape/browser/bookmarks-service"].getService(); 659 bmks = bmks.QueryInterface(Components.interfaces.nsIBookmarksService); 660 matt 1.1 661 waterson 1.22 var shortcutURL = bmks.FindShortcut(document.getElementById('urlbar').value); 662 matt 1.1 663 waterson 1.22 dump("FindShortcut: in='" + document.getElementById('urlbar').value + "' out='" + shortcutURL + "'\n"); 664 matt 1.1 665 waterson 1.22 if ((shortcutURL != null) && (shortcutURL != "")) { 666 document.getElementById('urlbar').value = shortcutURL; 667 } 668 matt 1.1 } 669 waterson 1.22 catch (ex) { 670 // stifle any exceptions so we're sure to load the URL. 671 } 672 matt 1.1 673 appCore.loadUrl(document.getElementById('urlbar').value); 674
XPConnect is most certainly getting init's or the JS error in question would never happen. In addition to apprunner, our build creates something called xpcshell. This is JS commandline shell that has xpconnect enabled. On my machine (where this bug is not happening) when I start xpcshell (in the bin directory) I can do: js> var foo = Components.classes["component://netscape/browser/bookmarks-service "].getService() js> foo [xpconnect wrapped nsISupports] js> foo.QueryInterface(Components.interfaces.nsIBookmarksService) [xpconnect wrapped nsIBookmarksService] js> This shows that the service has been registered and can be started up. Does this work on any machine where the bug is reproducable?
Oh, you could do the same thing in apprunner by putting this inside <script> tags in an html file and using 'dump' instead of 'print'. Perhaps this is obvious? :)
John is correct. We are getting a JS error on the line in navigator.js that says: var bmks = Components.classes["component://netscape/browser/bookmarks-service"].getService( ); The odd thing is that this seems to work OK in today's debug build. I'm seeing it fail with yesterdays (optimized) release-team build (I will download today's and see if it's still there). Maybe there's something funny whereby that component isn't built except in debug builds? There are try/catch around this code, BTW. That might be a sign that somebody expected it to fail in some situations (or it just might be coincidence). If John could change the xpconnect code to throw an exception, it might enable us to finesse the real problem (which I'll continue to dig into).
I know dp has done some stuff to make autoreg happen differently in release and debug builds. Is everyone always starting with a fresh components.reg? There are likely incompatibilities from day to day. The debug build would regenerate based on component dll timestamps. As I understand it the release build does not do that.
I was just looking at this with Bill Law. We were specifically looking at the xpcom.log that is available for release builds too. We saw the call to CreateInstance() bookmarks-service happen. but it returned without a pass/fail print although the code structure forces a pass or fail print. All other CreateInstance() calls do end with a pass/fail print in the log. Wierd! Jband, this aint the release build autoreg optimization thing. I am pulling a release build on unix and Bill said he is going to see this on windows to analyse the wierdity.
FWIW, I have done the work to make this kind of component manager failure throw a catchable JS exception rather than a JS error. My preference is to check this in along with other changes at the start of the M9 cycle. But if it turns out that it will do some good here I can split these changes off and get them in sooner. Let's wait and see how the weird stuff above works out.
*** Bug 9457 has been marked as a duplicate of this bug. ***
Radha has found the cause (more or less). Chris W. added code to recently to nsBookmarksService.cpp that effectively causes failures on bookmark service initialization (which is called during creation of the service). So I'm adding waterson to the cc: list (and emailing him to make sure we get his attention on this).
Let's try this fix. Index: nsBookmarksService.cpp =================================================================== RCS file: /cvsroot/mozilla/xpfe/components/bookmarks/src/nsBookmarksService.cpp,v retrieving revision 1.19 diff -c -r1.19 nsBookmarksService.cpp *** nsBookmarksService.cpp 1999/07/08 01:23:12 1.19 --- nsBookmarksService.cpp 1999/07/09 22:17:31 *************** *** 1548,1554 **** nsFileSpec bookmarksFile; rv = GetBookmarksFile(&bookmarksFile); ! if (NS_FAILED(rv)) return rv; rv = gRDFC->MakeSeq(mInner, kNC_BookmarksRoot, nsnull); NS_ASSERTION(NS_SUCCEEDED(rv), "Unable to make NC:BookmarksRoot a sequence"); --- 1548,1558 ---- nsFileSpec bookmarksFile; rv = GetBookmarksFile(&bookmarksFile); ! ! // Oh well, couldn't get the bookmarks file. Guess there ! // aren't any bookmarks to read in. ! if (NS_FAILED(rv)) ! return NS_OK; rv = gRDFC->MakeSeq(mInner, kNC_BookmarksRoot, nsnull); NS_ASSERTION(NS_SUCCEEDED(rv), "Unable to make NC:BookmarksRoot a sequence"); *************** *** 1682,1688 **** nsFileSpec bookmarksFile; rv = GetBookmarksFile(&bookmarksFile); ! if (NS_FAILED(rv)) return rv; rv = NS_ERROR_FAILURE; nsOutputFileStream strm(bookmarksFile); --- 1686,1696 ---- nsFileSpec bookmarksFile; rv = GetBookmarksFile(&bookmarksFile); ! ! // Oh well, couldn't get the bookmarks file. Guess there ! // aren't any bookmarks for us to write out. ! if (NS_FAILED(rv)) ! return NS_OK; rv = NS_ERROR_FAILURE; nsOutputFileStream strm(bookmarksFile);
Regardless, I dDon't understand why the try/catch block in navigator.js isn't catching the bookmarks exception?
chris didn't read every little word in the bug report :) I had/have some dumb odl code in xpconnect that I cribbed from old code in liveconnect that is reporting JS errors in this one stupid case (and some others) where it should be throwing JS exceptions.
See http://bugzilla.mozilla.org/show_bug.cgi?id=9547 for a rant on why we need the 'errors as exceptions' feature of the JS engine finished and enabled in mozilla.
Assignee: radha → waterson
Okay, I've verified that the above patch indeed solves the problem. I'll go bug chofmann to check in. Reassigning to self.
Status: NEW → ASSIGNED
Whiteboard: fix in hand
Do we understand why this works on debug but not on optimized builds.
BEcause thye code is #ifdef DEBUG.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Verified Fixed on apprunner build 1999070908: MacOS85 Win95 Linux6
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.