38787 - very slow response to ALT-L (open web location)

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Stephan Niemz]

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.

Comment 1

[Blake Ross]

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

Comment 2

[Stephan Niemz]

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.

Comment 3

[Stephan Niemz]

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)

Comment 4

[Blake Ross]

This wfm on win98 2000051108

Comment 5

[Asa Dotzler [:asa]]

over to XPApps

Comment 6

[don]

Bill, is this our bug?

Comment 7

[Bill Law]

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.

Comment 8

[sairuh (rarely reading bugmail)]

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

Comment 9

[sairuh (rarely reading bugmail)]

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

Comment 10

[Marko Macek]

Attachment: jprof for opening/closing lots of Alt+L dialogs.

Comment 11

[Marko Macek]

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

Comment 12

[Peter Trudelle]

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

Comment 13

[sairuh (rarely reading bugmail)]

*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.

Comment 14

[sairuh (rarely reading bugmail)]

ugh, these should go back to me...

Comment 15

[Stephan Niemz]

    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.

Comment 16

[Marko Macek]

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).

Comment 17

[Stuart Parmenter]

reassigning to dr

Comment 18

[David Hyatt]

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.

Comment 19

[Dan Rosen]

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).

Comment 20

[sairuh (rarely reading bugmail)]

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