User Agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/19.0 Firefox/19.0 Build ID: 20121013030542 Steps to reproduce: Launch firefox using xfe, by traversing down the directory tree and hitting enter to launch firefox instead of issuing the command "~/Util.Progs/firefox/firefox & " from a terminal emulator (in fluxbox). (Tested in both Firefox 11 and Firefox nightly downloaded ~ Sun, 14 Oct 2012 12:06:10 +0530 ) Actual results: No consequences to my actions of right clicking on a webpage or trying to view a drop down menu Expected results: right clicking on a webpage or trying to view a drop down menu should update the UI
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Summary: Cant right click when Firefox is launched with xfe in fluxbox → Non responsive GUI components when Firefox is launched with xfe in fluxbox
A small update, i notice that menu items like Tools, Bookmarks,etc also cant be accessed ( i.e clicking on them or pressing the keyboard shorcuts does not result in any changes to the screen)
I wonder whether xfe is providing a bad time in the DESKTOP_STARTUP_ID it sets. After running "xprop | grep LEADER" to get the client leader window id for firefox, what does "xprop -id <window id #> | grep STARTUP" output, when run shortly after Firefox has started? How does the TIME field at the end of that property compare with times output by xev?
Created attachment 671288 [details] console output from xprop and xev comands console output from xprop and xev comands as requested by karlt
@karlt: Things like Audacious ( a music player ) and evince ( a pdf file reader) seem to function as expected when launched from xfe
(In reply to Harish Badrinath from comment #3) > _NET_STARTUP_ID(UTF8_STRING) = "Xfe/'|home|code|Util.Progs|firefox|firefox'/3811-0-sekon.1_TIME1350266833" > PropertyNotify event, serial 8, synthetic NO, window 0x2000001, > atom 0x27 (WM_NAME), time 128077227, state PropertyNewValue Thanks. This is saying that Firefox started either 35 days before or 14 days after xev started. If that isn't the case then Xfe is providing the wrong time. (In reply to Harish Badrinath from comment #4) > @karlt: Things like Audacious ( a music player ) and evince ( a pdf file > reader) seem to function as expected when launched from xfe I can't imagine how focus stealing prevention could work properly unless fluxbox has a mechanism for detecting crazy timestamps. This is what prevents an application taking focus after the user has started typing in another window. Even with some sort of bad timestamp detection, there is likely going to be a time bomb remaining where for some period of time the timestamps are close enough to expected values that the bug can't be detected. Other apps may not use gdk_x11_display_get_user_time() and so may not be affected in the same way. Ideally Gecko should provide the event used to initiate the pointer grabs (for the popup windows) and get the timestamp from that, but passing this through the cross-platform code could be difficult. Some popups are initiated off nsXULPopupShowingEvent events and so a pointer to the native event would not be suitable; we'd need to copy the timestamp. gtk_get_current_event_time() is not suitable because of it doesn't do what we need in nested event loops. I guess we could implement our own gdk_x11_display_get_user_time(), but there would still be bugs remaining because the real bug is in Xfe, or in whatever is giving Xfe that timestamp.
@karl: Thanks for the helpful explanation. I have filed a bug report for xfe at https://sourceforge.net/tracker/?func=detail&aid=3577257&group_id=64835&atid=508822 Regards, Harish
You need to log in before you can comment on or make changes to this bug.