Context menu and drop down list are slow to appear

Bug #305531 reported by Marc Gariépy on 2008-12-05
26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
XULRunner
New
Unknown
xulrunner-1.9 (Ubuntu)
Medium
Unassigned

Bug Description

When brigning up a context menu, in firefox by a right click in a web page the context menu take 2-3 second to appear, the same thing happen when clicking a drop down list.
The same bug appear in liferea when rightclicking in the message display.

This is on a ltsp-cluster setup on Intrepid.

Marc Gariépy (mgariepy) on 2008-12-05
description: updated
Stéphane Graber (stgraber) 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.

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

Changed in xulrunner-1.9:
importance: Undecided → Medium
status: New → Triaged

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

Marc Gariépy (mgariepy) wrote :

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

Stéphane Graber (stgraber) wrote :

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.

SteveA (steve-encoremusic) wrote :

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.

Nick Porter (nick-porter) wrote :

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.

SteveA (steve-encoremusic) 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.

Alexander Sack (asac) wrote :

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

SteveA (steve-encoremusic) 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.

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

SteveA (steve-encoremusic) wrote :

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.

Marc Gariépy (mgariepy) wrote :

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.

Briano (bruiz-moverotech) wrote :

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.

Alkis Georgopoulos (alkisg) wrote :

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.

Alexander Sack (asac) wrote :

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

Alexander Sack (asac) wrote :

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?

SteveA (steve-encoremusic) wrote :

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.

Changed in xulrunner:
status: Unknown → New
Bryce Harrington (bryce) wrote :

This is a dupe of 277069

John Vivirito (gnomefreak) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.