From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; m15) BuildID: M15 aka 2000042619 (the "nightly" build is not current) When pressing Alt-L for the first time, nothing happens at all. Several seconds later, the desired "Open Web Location" pop up window appears finally. Reproducible: Always Steps to Reproduce: 1.start-mozilla 2.press Alt-L Actual Results: it takes very long (several seconds) until anything happens at all. Expected Results: The pop up window should appear immediately, or at least within no more than one second. If this isn't possible, there should be at least some indications that there's something happening, like the cursor changing to an hour glass or similar.

Shouldn't this be Ctrl+L, or is this something specific with Solaris that I don't know?

No, with the Netscape browser (and Mozilla, too) key shortcuts have always been Alt+something on UNIX (Solaris, Linux, AIX, whatever) and Ctrl+something on Windoze as far as I know.

By the way, this happens on Linux (Build 2000050513), too, so I'm changing Platform and OS to "all" since I don't know any other way to select more than one. Blake, can you confirm this on Windows, too? (With Ctrl-L, of course)

This wfm on win98 2000051108

over to XPApps

Bill, is this our bug?

This seems a bit slow to me, too, but only on my Linux box. I get 1 sec. or faster response on Win98/WinNT/Mac vs. approximately 4 sec on Linux. All but Win98 are debug builds. The Linux box is dual PPro 200, the others faster to varying degrees (WinNT PII266, Win98 PIII500, Mac G4-?00). In any case, I'm not sure there's a problem and if there is, it isn't an xpapps thing. It seems opening any new windows is slower on Linux (Alt-N took about 12 seconds for me). I'm going to resolve this WORKSFORME. If something extra (aside from standard performance enhancement which is ongoing) needs to be done, please reopen it, change the summary to something more generic, and change the component to xptoolkit/widgets. Sorry if I appear to be blowing you off. We've just got so many bugs we need to try to consolidate some of them.

thx for the info, bill. i'll reopen and assign it to pavlov, our linux man in xptoolkit... :-)

pavlov, is the really your ball o'wax? doesn't appear to be xpapps, according to bill...

I attached a jprof output. See also bug 39554 and bug 28639.

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner. feel free to add me to the cc list (unless am the Reporter) of any of these, if you have any questions/etc.

ugh, these should go back to me...

When building with --disable-debug and --enable-optimize I'm getting a response time of about one seconds now, which is not perfect but acceptable. So if one second is enough for you, it would be okay for me to close this bug. Still I think it would be good to change the pointer to an hourglass or similar to avoid confusing an unexperienced user.

On Linux: On 4.x the response is nearly instantaneous (2nd try). On mozilla it's from 0.5 to 1 second (2nd try). First try is also noticably slower in mozilla. I don't thing this is even close to being acceptable. (<0.2 seconds would be for acceptable such a simple dialog although <0.1 would be preferable).

reassigning to dr

Note that I checked in a fix recently that should have massively sped up this dialog. It can be further sped up by fixing the chrome URL loaded by the XUL file to be chrome://navigator/skin/ instead of chrome://navigator/skin/navigator.css. The usage of the alternative form is causing a chrome cache miss, so we're reloading the style sheet the first time the dialog is opened.

Checked in hyatt's fix. Also modified numerous other xul files with the same mistaken chrome URL (it is debatable whether canonifying all chrome URLs before caching them will be good for performance -- opening new bug 48104 to investigate).

vrfy fixed on linux/mac/winnt using 2000.09.15.06/8/5 opt comm bits.