Open Bug 1259520 Opened 9 years ago Updated 2 years ago

Pull down menus close when I try to choose menu items

Categories

(Firefox :: Menus, defect)

45 Branch
Unspecified
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: m.grosser, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:39.0) Gecko/20100101 Firefox/39.0 Build ID: 20150806001005 Steps to reproduce: I am using Linux in a VirtualBox environment and run Firefox remotely via SSH -Y (with X forwarding). Firefox itself is running on the Linux host system. With the mouse, I click on the 'View' menu, the pull down menu opens, I click on the 'Text Encoding' sub menu. What happens? The 'View' menu closes. Via Keyboard, I press <Alt>+<V>, teh 'View' menu opens, I press 'C' to open the 'Text Encoding' sub menu. What happens? The 'View' menu closes. It is not possible anymore to get the 'Text Encoding' sub menu. This bug exists since some versions of Firefox. Older Firefox versions did not have such a bug. Generally, the menus close when I try to open a sub menu either via mouse or via keyboard, no matter how. Actual results: When I try to open a sub menu, the main menu closes. Expected results: When I try to open a sub menu, the main menu stays open and the sub menu opens.
Component: Untriaged → Menus
Effected are newer Firefox versions like version '45.0.1' or version '39.0.3'. This bug occurs in an attenuated variant when I use Firefox on a Linux host computer directly (without VirtualBox) and without SSH. But generally speaking, this bug is very annoying. There is an older Firefox version for Debian Lenny (probably Iceweasel 3.0.6, wich I use at home in a VirtualBox environment. This old 3.0.6 version runs rock solid everywhere. I never observed problems with disappearing menus when I worked with older Firefox versions.
So, because this is a very annoying bug, I took some time to investigate further. I downloaded several versions of Firefox from this URL: https://ftp.mozilla.org/pub/firefox/releases/ After selecting a version, I chose this path each time: linux-x86_64/en-US/ I downloaded these versions: - firefox-10.0.2.tar.bz2 - firefox-11.0.tar.bz2 - firefox-12.0.tar.bz2 - firefox-13.0.tar.bz2 - firefox-13.0.1.tar.bz2 - firefox-17.0.1.tar.bz2 - firefox-20.0.1.tar.bz2 - firefox-37.0.2.tar.bz2 - firefox-39.0.3.tar.bz2 Then, I systematically installed one Firefox version in the '/opt' directory, tried it, deleted it and installed the next one. Version 10.0.2, version 11.0 and version 12.0 are OK: - The menus are absolutly stable: I can click them, they open, I change the mouse position, new menus replace the old one (depending on the mouse position), and they never close on their own. They close only when I want them closed (when I click outside of a menu). Version 13.0 is the first version that has the bug: - I do the same as in (for example) version 12.0, but a menu closes after I changed the mouse position a few times. I did this test on a Debian Wheezy virtual Machine running in VirtualBox. Window manager ist FVWM 2.5.30. There must be a change that was introduced in Firefox 13. I wonder if there is an option that I can toggle to switch Firefox to the behaviour before version 13. Is there something that I can configure? If not, can anybody identify and fix this bug please?
Can you use the tool mozregression to narrow down the regression, please. http://mozilla.github.io/mozregression/
Flags: needinfo?(m.grosser)
This is not a spontaneous action done within few minutes: - In Debian Wheezy (where my playground for Firefox tests exists), mozregression-gui.tar.gz needs a too new glibc library to run - In Debian Jessie, mozregression-gui.tar.gz throws an HTTPError exception. It looks like I have to invest some extra hours of time to investigate. What I already know is: - Firefox 12 (the good one) was obviously build on 2012-04-21 - Firefox 13 (the bad one) was obviously build on 2012-06-01 I don't even understand what exactly mozregression does. Apparently, it wants to download something: - Is there a way to give mozregression some proxy settings to let it access the world wide web? - Does an older version of mozregression exist that runs in Wheezy environments (so that I don't have to pollute a real machine with experimental software)? I could find out the answers myself, but I have to plan extra time in the early morning or late evening to investigate things that are not done within 5 minutes or so.
Flags: needinfo?(m.grosser)
I tried something with the command line version of 'mozregression'. As 'root' on wheezy: # apt-get install python-pip # pip --proxy=user@proxy-server:proxy-port install -U mozregression As 'user' on wheezy: # http_proxy=http://user:password@proxy-server:proxy-port # https_proxy=http://user:password@proxy-server:proxy-port # echo $http_proxy # echo $https_proxy # mozregression --good 12 --bad 13 Result: > 0:10.08 CRITICAL: Unable to get latest version from pypi. > 0:10.08 INFO: Using date 2012-03-13 for release 13 > 0:10.08 INFO: Using date 2012-01-31 for release 12 > Exception in thread Thread-1: > Traceback (most recent call last): > File "/usr/lib/python2.7/threading.py", line 552, in __bootstrap_inner > self.run() > File "/usr/lib/python2.7/threading.py", line 505, in run > self.__target(*self.__args, **self.__kwargs) > File "/usr/local/lib/python2.7/dist-packages/mozregression/build_range.py", line 94, in __getitem__ > return self._future_build_infos[i].build_info > File "/usr/local/lib/python2.7/dist-packages/mozregression/build_range.py", line 41, in build_info > self._build_info = self._fetch() > File "/usr/local/lib/python2.7/dist-packages/mozregression/build_range.py", line 35, in _fetch > return self.build_info_fetcher.find_build_info(self.data) > File "/usr/local/lib/python2.7/dist-packages/mozregression/fetch_build_info.py", line 243, in find_build_info > build_urls = self._get_urls(date) > File "/usr/local/lib/python2.7/dist-packages/mozregression/fetch_build_info.py", line 219, in _get_urls > month_links = self._get_month_links(url) > File "/usr/local/lib/python2.7/dist-packages/mozregression/fetch_build_info.py", line 206, in _get_month_links > self._cache_months[url] = url_links(url) > File "/usr/local/lib/python2.7/dist-packages/mozregression/network.py", line 75, in url_links > response = retry_get(url, auth=auth) > File "/usr/local/lib/python2.7/dist-packages/mozregression/network.py", line 27, in retry_get > args=(url,), kwargs=karwgs) > File "/usr/local/lib/python2.7/dist-packages/redo/__init__.py", line 152, in retry > return action(*args, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/mozregression/network.py", line 52, in _default_get > return _get(*args, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 480, in get > return self.request('GET', url, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 468, in request > resp = self.send(prep, **send_kwargs) > File "/usr/local/lib/python2.7/dist-packages/requests/sessions.py", line 576, in send > r = adapter.send(request, **kwargs) > File "/usr/local/lib/python2.7/dist-packages/requests/adapters.py", line 432, in send > raise ConnectTimeout(e, request=request) > ConnectTimeout: HTTPSConnectionPool(host='archive.mozilla.org', port=443): Max retries exceeded with url: /pub/firefox/nightly/2012/01/ (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x2af4510>, 'Connection to archive.mozilla.org timed out. (connect timeout=30.0)')) > > ^C > Interrupted. Question: - Is my chosen way to transmit my proxy user name and proxy user password a correct way? Though I don't like the way, because I have to manually clean '.bash_history', my approach was even not successful. - How am I supposed to work with mozregression with a proxy server between me and the Internet?
Somebody could post pathes for 64-bit Linux binaries of officially published weeklies that I could download and install. This would match the approach that I used to narrow down the versions 12 and 13 anyway.
> https://ftp.mozilla.org/pub/firefox/nightly/2012/01/ > > Dir 2012-01-31-03-11-50-mozilla-central/ > Dir 2012-01-31-04-02-05-profiling/ > Dir 2012-01-31-04-02-06-fx-team/ > Dir 2012-01-31-04-02-08-elm/ > Dir 2012-01-31-04-02-34-mozilla-inbound/ > Dir 2012-01-31-04-20-11-mozilla-aurora/ > Dir 2012-01-31-04-34-01-mozilla-inbound/ > Dir 2012-01-31-04-49-32-mozilla-inbound/ > Dir 2012-01-31-05-19-32-mozilla-inbound/ > Dir 2012-01-31-05-21-32-mozilla-inbound/ > Dir 2012-01-31-07-39-25-elm/ > Dir 2012-01-31-07-54-46-ux/ > Dir 2012-01-31-12-39-22-elm/ > Dir 2012-01-31-17-48-05-elm/ > Dir 2012-01-31-mozilla-aurora-debug/ > Dir 2012-01-31-mozilla-central-debug/ > Dir 2012-01-31-mozilla-esr10-debug/ > Dir 2012-01-31-mozilla-inbound-debug/ --> 18 directories only for the start point > https://ftp.mozilla.org/pub/firefox/nightly/2012/03/ > > Dir 2012-03-13-03-11-12-mozilla-central/ > Dir 2012-03-13-04-02-04-oak/ > Dir 2012-03-13-04-02-06-fx-team/ > Dir 2012-03-13-04-02-36-mozilla-inbound/ > Dir 2012-03-13-04-02-42-maple/ > Dir 2012-03-13-04-02-42-profiling/ > Dir 2012-03-13-04-20-10-mozilla-aurora/ > Dir 2012-03-13-05-43-14-mozilla-central/ > Dir 2012-03-13-09-04-04-mozilla-central/ > Dir 2012-03-13-14-35-43-oak/ > Dir 2012-03-13-14-52-16-ux/ > Dir 2012-03-13-20-18-59-oak/ > Dir 2012-03-13-mozilla-aurora-debug/ > Dir 2012-03-13-mozilla-central-debug/ > Dir 2012-03-13-mozilla-inbound-debug/ --> 15 directories only for the end point Which of the 18 or 15 directories does contain a nightly build that comes closest to an official Firefox biuld? Which should I choose? Elm? Ux? Fx-team? What does these abbreviations mean? Is there a list for reference?
Nightlies are in the repository mozilla-central, like https://ftp.mozilla.org/pub/firefox/nightly/2012/03/2012-03-01-03-11-35-mozilla-central/ So you can download each nightly (by dichotomy to reduce the range fastly) and test it. After that, when you get the last good build and the first bad build, report the build ID of both builds (in a about:buildconfig under "Source")
So, this is my result: 2012-01-31-03-11-50-mozilla-central___good 2012-02-01-03-11-46-mozilla-central___good 2012-02-05-03-11-29-mozilla-central___good 2012-02-07-03-11-36-mozilla-central___good 2012-02-08-03-12-53-mozilla-central___really_bad 2012-02-10-03-11-50-mozilla-central___really_bad 2012-02-15-03-11-55-mozilla-central___bad 2012-03-13-03-11-12-mozilla-central___bad And here are the IDs: -2012-02-07-03-11-36-mozilla-central___good --> http://hg.mozilla.org/mozilla-central/rev/b077059c575a -2012-02-08-03-12-53-mozilla-central___really_bad --> http://hg.mozilla.org/mozilla-central/rev/4b9608fd670c 'really_bad' means: After a menu closes, I am never able to open a new menu. I have to close Firefox and open a new one to be able to use the menu again.
(In reply to m.grosser from comment #9) > -2012-02-07-03-11-36-mozilla-central___good > --> http://hg.mozilla.org/mozilla-central/rev/b077059c575a > -2012-02-08-03-12-53-mozilla-central___really_bad > --> http://hg.mozilla.org/mozilla-central/rev/4b9608fd670c Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=b077059c575a&tochange=4b9608fd670c
Maybe I'm wrong but I dont see any potential regressing bug in this pushlog.
Is anybody able to reproduce the behavior described by me?
I determined the point between 'really_bad' and 'bad': - 2012-02-10-03-11-50-mozilla-central___really_bad - 2012-02-13-03-11-53-mozilla-central___really_bad - 2012-02-14-03-12-27-mozilla-central___really_bad_sometimes --> http://hg.mozilla.org/mozilla-central/rev/60edf587f4af - 2012-02-15-03-11-55-mozilla-central___bad --> http://hg.mozilla.org/mozilla-central/rev/d45c7d7b0079 Perhaps, this helps.
(In reply to m.grosser from comment #0) > It is not possible anymore to get the 'Text Encoding' sub menu. [...] > When I try to open a sub menu, the main menu closes. Just to be clear -- is this bug happening only for the Text Encoding submenu, or it happening for all submenus everywhere?
(In reply to Loic from comment #10) > Pushlog: > https://hg.mozilla.org/integration/mozilla-inbound/ > pushloghtml?fromchange=b077059c575a&tochange=4b9608fd670c I don't see anything either, although it's interesting that bug 724776 is in that range. But seems like a clear bugfix, so not sure how it would cause a problem. 1) Can you reproduce this with a new profile / in Safe Mode? I'd almost suspect an addon... 2) Assuming this is Text Encoding specific, what happens in a current Firefox with the Text Encoding button? (You'll have to enter Customize mode via the menu button (☰), and add Text Encoding to the toolbar). 3) Are there any errors in Tools -> Web Developer -> Browser Console?
> 1) Can you reproduce this with a new profile / in Safe Mode? I'd almost suspect an addon... - New profile: Yes - 'firefox -safe-mode': Yes > 2) Assuming this is Text Encoding specific, what happens in a current Firefox > with the Text Encoding button? (You'll have to enter Customize mode via > the menu button (☰), and add Text Encoding to the toolbar). It is not Text Encoding specific. My patience snapped last Thursday evening when I tried to change the Text Encoding of a text document to print it with correct German umlauts and was not able to perform that simple job. This was the reason for me to finally tackle the whole issue, file a bug here and to investigate further. All Firefox menus (and Thunderbird menus too) are affected. They are less affected when I work locally and they are more affected when I work remotely via 'SSH -Y'. Working remotely leads to the situation that some submenues are not useable at all. > 3) Are there any errors in Tools -> Web Developer -> Browser Console? Yes. See screenshot 'errors_browser_console.png'. I will upload it instantly. Meanwhile, I concluded that there must be a window manager setting that does not cope with Firefox versions newer than version 12. I posted at the FVWM list and started a survey. My survey should appear in the mail archive soon: https://www.mail-archive.com/fvwm@lists.math.uh.edu/ A deep link is not available currently (because it takes some time until the archive adds new threads). My next task is: - Finding the difference between a naked FVWM without any config and my complex configuration. But even then, when I can say which config setting does not cope with Firefox and Thunderbird anymore, the question remains: Why does Firefox newer than version 12 does not work correctly whereas Firefox until version 12 worked without any problems as far as menus are concerned?
Screenshot 'errors_browser_console.png': Tools -> Web Developer -> Browser Console I removed the Firefox config in the home directory, started Firefox in version 39.0.3, clicked around (opened menus and provoked the closing of some menus) and opened the Browser Console.
It seems that Firefox newer than 12 closes its menus when a periodic scheduler performs an operation on another window: > AddToFunc StartFunction > + I Schedule Periodic 2000 crashGuardPager > > DestroyFunc crashGuardPager > AddToFunc crashGuardPager > + I All ("minipager") Nop The config line '+ I All ("minipager") Nop' does nothing with a pager window called 'minipager', but this 'nothing' seems to be enough that a menu closes when I try the select another menu or a sub menu. My suspiction: Every time a window manager does something with another application in the background, Firefox newer than 12 closes a menu when I'm about to choose a sub menu or another menu. I could keep isolating these issues, but for that, I should be able to use the newest version of FVWM (version 2.6.6 to be accurate), and this fails of my inability to compile FVWM straight away because some "X11 libraries or header files could not be found". So once again, nothing is spontaneous. It takes a huge amount of effort to simply get a current FVWM compiled and installed, and for that I must be prepared first. So, I will have a break, will prepare my next move and will be back when I have something foolproof that I can demonstrate.
Pale Moon version 26.1.1 (x64) is affected as well.
Do you still see this issue?
Flags: needinfo?(m.grosser)
OS: Unspecified → Linux
Yes, nearly everyday. I created a workaround some months ago: I created some hotkeys within my FVWM configuration. I hit one hotkey to switch all schedulers off. Then all Firefoxes newer than version 12 (and Icedove / Thunderbird too) don't have the bug. I hit another hotkey to switch my schedulers on, so they can continue with their work, but then the bug reappears. I have to decide what I need for the given situation: Menus that do not disappear or schedulers that do their work in the background of the window manager. It is not nice to have to depend on such a workaround, especially because Firefox older than version 13 didn't need such kind of workaround, so this bug is clearly a regression bug, but when I have to heavily use the menus, then the workaround helps.
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.

Flags: needinfo?(m.grosser)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: