*Summary When you select Bookmarks|Manage Bookmarks, a seemingly random 32bit hexadecimal (e.g. $239cd764) string is appended to the current url and the browser tries to load it. *To Repro Select the top level Bookmarks menu then Manage Bookmarks... th en bring the browser window back to front and observe. *Build info This bug is XP and was tested and reproduced on RH Linux 5.2 (1999072815) MacOS8.5 (1999072814) and WinNTsp4 (1999072815) *Expected Result Launching the Manage Bookmarks tree wiew shou ld have no effect in the browser window. *Actual Results As mentioned the browser tries to load the new url and typically leads to a file not found error. *Irrelevant Footnote the string is the same each time you select the option, but different after restarting the app.ˇ

The BrowserEditBookmarks(() function in navigator.js is calling toolkitCore.ShowWindow() which seems to be in the chain of nastiness that causes this. Reassigning to danm as I know he's worked on window.open. Maybe he knows something about the toolkit appcore. Dan?

This bug also occurs when selecting Bookmarks|Add Current Page.

!%@#$! reassigning to !@!@# rjc because there's !$#!@# RDF on the $!%!$ stack at the %!#$!^ time, too, %#$@!%!!! On second thought, guess I'll reassign to bookmarks boy. Hey guys, the window.open code is doing exactly what it's being told to do. OpenBookmarkURL, a function in navigator.js, calls as its last fading action, window.content.location=url. navigator.js being part of navigator.xul, "window" refers to the main browser window. url, in this case, is some hex thing coming out of the bookmarks datasource from the line "url=node.getAttribute('id')": the very first thing that OpenBookmarkURL does. So there's code in navigator.js that says "pull up some random hex thing from a likely-sounding RDF data source and send the main browser window there." It's interpreted as a relative URL and oddly enough, that's just what happens.

Steve, is this our bug?

Hey, DAN! OpenBookmarkURL isn't ever being called when you choose "Bookmarks|Manage Bookmarks". Look at the BrowserEditBookmarks() function in navigator.js. As I mentioned, this is what is called: toolkitCore.ShowWindow("resource:/res/samples/bookmarks.xul",window); so, why are the contents of the location bar ever changing???

Response to above comment from rjc: I'm confused by your assertion that the function is never called. If you put the following line: dump("***opening " + url + "\n"); in OpenBookmarkURL(), just before the line that reads window.content.location.href=url; (line 461 of navigator.js rev 1.9), launch apprunner and select "Manage Bookmarks" from the menu, it prints to the console window ***opening $190ae65b and then the window from which you made the menu selection tries to navigate to <wherever it already was>/$190ae65b Additional dump()s reveal that the url string is coming from line 431, var url = node.getAttribute('id');

OK, let's take a step back. Look in navigator.xul around line #641 at the onaction() handler for when the "Manage Bookmarks" menu command is used. It is: onaction="BrowserEditBookmarks();" Now look in navigator.js at that function. It is: function BrowserEditBookmarks() { var toolkitCore = XPAppCoresManager.Find("toolkitCore"); if (!toolkitCore) { toolkitCore = new ToolkitCore(); if (toolkitCore) { toolkitCore.Init("toolkitCore"); } } if (toolkitCore) { toolkitCore.ShowWindow("resource:/res/samples/bookmarks.xul",window); } } so that is why I say OpenBookmarkURL() is never getting called. Perhaps I should restate to say that OpenBookmarkURL() doesn't APPEAR that it should ever be called. So, why is it being called? What's calling it? Answers to these questions will probably end up fixing this bug.

Thank you for all your investigations. I checked in a fix. The Bookmarks menu had an action handler that called OpenBookmarkURL. I removed that one since the individual items already had the same action handler.

VERIFIED fixed for all 1999080908 builds