Context menu and drop down list are slow to appear

The easiest way to reproduce this bug is to have a X server accepting remote connections then start firefox from another computer using DISPLAY=<ip>:0

Firefox is usually fast (as if it was local) but when you right-click it takes 2-3 seconds before the drop-down menu appears. This has also been confirmed with liferea, so it's likely xul-related.

It makes the user experience a lot worse than it was with Hardy's firefox/xul where it was local-like performances for drop-down menus and contextual menus.

This has been tested on the exact same network and same computers on both Hardy and Intrepid, so the network performances, cpu usage or video drivers are not at fault (tried with intel, via and ati hardware).

On Fri, Dec 05, 2008 at 06:47:37PM -0000, Stéphane Graber wrote:
> The easiest way to reproduce this bug is to have a X server accepting
> remote connections then start firefox from another computer using
> DISPLAY=<ip>:0
>
> Firefox is usually fast (as if it was local) but when you right-click it
> takes 2-3 seconds before the drop-down menu appears. This has also been
> confirmed with liferea, so it's likely xul-related.

does liferea use xul based context menus at all?

If so, do oyu also experience the "right click selects random context
menu" bug? e.g. firefox fires a context (or even normal menu) entry
when you just click (moust down and up) ... i always thought this only
happened when the "menu" construction took some time.

 - Alexander

on liferea the context menu appear only in the bottom left part of the ui (see attached picture) all the other part work fine.

- Marc

Ok, so only the XUL part of the UI shows the context menu bug.
As it's a regression from Hardy, I'm tagging the bug as regression.

I also have this problem. I am also running ltsp and on all of the clients, firefox takes several seconds for a right click context menu and several seconds to display drop down menu options. Directly on the server, though, it works fine.

So, it has something to do with running firefox remotely.

This also appears to affect the drop down that appears when choosing from a history of previously entered values in a form field on firefox. Running locally on the machine console, the drop down appears immediately. Running over remote X11 causes a 2-3 second delay in the drop down appearing.

Again, this is on Intrepid in an LTSP setup - though using the LDM_DIRECTX=True option rather than ssh tunnelled X11.

I am also using LDM_DIRECTX=True, but I did just change it to false for a client and tested again - and that wasn't it. Firefox is still slow.

I'm having a hard time picturing what Firefox could be doing differently for context menus and drop down options when run remotely vs. locally. Obviously it is doing something different, but I'm pretty much out of ideas.

On Thu, Dec 18, 2008 at 03:48:35PM -0000, SteveA wrote:
> I am also using LDM_DIRECTX=True, but I did just change it to false for
> a client and tested again - and that wasn't it. Firefox is still slow.
>
> I'm having a hard time picturing what Firefox could be doing differently
> for context menus and drop down options when run remotely vs. locally.
> Obviously it is doing something different, but I'm pretty much out of
> ideas.
>
So this is about menus displayed by gecko? Can you please try to
disable assistive technolgies in gnome preferences (ATM) and see if
things go faster?

 - Alexander

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Sack wrote:
> So this is about menus displayed by gecko? Can you please try to
> disable assistive technolgies in gnome preferences (ATM) and see if
> things go faster?
>
>
> - Alexander
Hi, we just tried a gnome session with AT disabled both in the menu
and in the session preferences, didn't make any difference.

Stéphane
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklKygkACgkQjxyfqkjBhuzwHgCcCcKyagafFl7IHupy9mydvXwm
3I8An33mwL1ZV1r4NMiRRSqRAiHm1c+q
=kEow
-----END PGP SIGNATURE-----

In sessions, I have the AT SPI Registry Wrapper turned off, and under assistive technologies preferences I have "Enable assistive technologies" unchecked. Firefox right clicks and drop downs slow. I turned on the at spi registry wrapper and enabled assistive technologies and firefox is still slow.

On Thu, Dec 18, 2008 at 10:24:15PM -0000, SteveA wrote:
> In sessions, I have the AT SPI Registry Wrapper turned off, and under
> assistive technologies preferences I have "Enable assistive
> technologies" unchecked. Firefox right clicks and drop downs slow. I
> turned on the at spi registry wrapper and enabled assistive technologies
> and firefox is still slow.
>

I assume you also disabled both?

 - Alexander

I should have been more clear. Yes, both disabled is my normal running condition and the error does occur there. I tested with both enabled and the error still occurs.

I have tried the upstream version of firefox, and i get the same result.
The drop down and right click menu are slow to appear.

I would like to request that the importance level of this issue be raised. This obviously effects EVERY user who is using firefox in an LTSP setup, using Intrepid. We are trying to deploy this configuration in our office and this is one of the biggest issues that we have have, a the moment. If anyone has a temporary work around please let everyone know.

An easier way to reproduce the bug is with
ssh -Y localhost (or -X)
firefox

There's a big delay there as well, no need for network or different computers to reproduce it...
And about:config is a xul app, the delay also happens there.

do you have accessibility enabled? can you try to disable that and see if performance improves?

is it correct that its also reproducible with two recent desktop/laptops running on the same subnet when using x11 forwarding? Does it also happen when using x11 forwarding to localhost?

This bug appears to be the sames as

https://bugzilla.mozilla.org/show_bug.cgi?id=475713

and they supposedly have it tracked down to a component of X11, not firefox.
I have not tried their fix, so I don't know if it works.

This is a dupe of 277069

Marked as dupe of bug 277069
Bryce Thanks for finding the dupe