Closed Bug 774892 Opened 13 years ago Closed 12 years ago

Unable to type in Firefox if it's started with focusmanager.testmode enabled on Linux

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox15 - ---

People

(Reporter: davehunt, Unassigned)

References

Details

With the testing mode introduced in bug 704583 enabled (used by Mozmill and Selenium) it is not possible to use the keyboard to interact with Firefox. This only appears to be an issue when the preference is set on launch, and not when set later. You can replicate this by running the following: mkdir ~/fmtm echo 'user_pref("focusmanager.testmode", true);' > ~/fmtm/user.js firefox -profile ~/fmtm
Doesn't look like a real bug to me. If you're using testing mode, then you are. If you use browser normally, then you shouldn't use testing mode. But I guess in testing mode we could set focus initially to some sane value.
To clarify, this means that Selenium is also unable to type.
Component: General → Event Handling
Product: Firefox → Core
Probably we should activate the first visible window, or Selenium should do it.
While I realize there's no fix or even solid diagnosis, yet, I'd like to start tracking this for inclusion into the next release(s) -- it's critical to us getting much-needed parallelization on our Selenium Grid, and thus, much less capacity to build out. Also not sure if this affects Marionette, but I've heard that's not currently designed to run multi-process.
tracking-firefox15: --- → ?
(In reply to Stephen Donner [:stephend] from comment #4) > While I realize there's no fix or even solid diagnosis, yet, I'd like to > start tracking this for inclusion into the next release(s) -- it's critical > to us getting much-needed parallelization on our Selenium Grid, and thus, > much less capacity to build out. Also not sure if this affects Marionette, > but I've heard that's not currently designed to run multi-process. Hi Stephen - we only track bugs that have user impact. That being said we'd still be happy to uplift a low-risk fix as necessary, or to follow up on this bug if you hit any roadblocks. Email us at release-mgmt@ if so.
tracking-firefox15: ? → -
A menu option or UI toggle to change the state of the focus manager would be the ideal way to do this (since mouse interactions still work). Since this is related to firefox functionality, it'd be best if this were presented via Firefox itself.
I'm not sure we need any UI for toggling the mode. It sounds to me that activating the first visible window might work. Is there an easy way to test this Olli?
Blocks: 758233
Activating the first window sounds like an excellent solution. Olli, you've mentioned Selenium could do that - could you provide some details on how?
As this affects Selenium and Mozmill (there may be others, although I'm not sure), could we examine the possibility of activating the first window within Firefox itself?
What's the status of this? I just stumbled upon this bug and found out that this is what breaks keyboard input for me when using the mozregression tool to determine regression ranges. I thought my window manager is somehow broken.
Neil: can this be easily fixed in the focus code, per comment 1?
I don't think it makes sense to change this. The testing mode is intended so that you can run the tests in the background. Having it activate the window defeats the purpose of having the testing mode.
Neil: The tests are unable to type into Firefox at all, so we definitely need a fix here. If it's not activating the initial window then what would you suggest?
(In reply to Neil Deakin from comment #13) > I don't think it makes sense to change this. The testing mode is intended so > that you can run the tests in the background. Having it activate the window > defeats the purpose of having the testing mode. Clearly there are different understandings of what the testing mode is for, here... Are you saying it's impossible make typing in the window work while in testing mode, without breaking the ability to run tests in the background?
Actually, I was responding to comment 10. Since this is Linux specific, there's probably some window manager related detail that causes the key events to get sent to the wrong place which I'm investigating.
Or X. I have seen this in multiple window managers (e.g. I use fluxbox....not exactly the most common).
Is the test framework launching firefox as a background window or is it launching it in the foreground and it doesn't work?
generally -foreground is explicitly used
Selenium also currently launches Firefox with -foreground, however the hope is that this will no longer be necessary once focus issues are resolved.
FWIW -foreground is a Mac-only parameter that deals with "activation" at the OS level (http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#3053), and may not be relevant to the underlying Gecko focus code.
So -foreground is a red herring since this is linux only. Not sure what 'foreground' vs 'background' window means then wrt comment 18.
When you run the tests through your test framework, you execute firefox in some way. Does the firefox window that the test framework opens appear in the foreground, above other windows and focused, or in the background or not focused?
(In reply to Neil Deakin from comment #23) > When you run the tests through your test framework, you execute firefox in > some way. Does the firefox window that the test framework opens appear in > the foreground, above other windows and focused, or in the background or not > focused? Yes, it is opened in the foreground. To reproduce, install mozrunner (`easy_install mozrunner`, if you have easy_install available) from http://pypi.python.org/pypi/mozrunner and run `mozrunner $(which firefox)`
This issue is not only on Linux, but on Windows too. I'm using mozregression regularly and I found it changed focusmanager.testmode to true for the testing profile (according to https://github.com/mozilla/mozbase/blob/master/mozprofile/mozprofile/profile.py#L249 I guess). Now each time I seek a Flash video (like on YouTube), the focus of Firefox is stolen by the Flash plugin, and I can't use anymore the keyboard (in the location bar e.g.) or the mouse wheel scrolling. I need to switch to another application to get the focus back. Of course, resetting focusmanager.testmode fixes the issue. Question: Is this interaction between focusmanager.testmode enabled and the Flash plugin a real bug or an expected behavior?
(In reply to Loic from comment #25) > This issue is not only on Linux, but on Windows too. > > I'm using mozregression regularly and I found it changed > focusmanager.testmode to true for the testing profile (according to > https://github.com/mozilla/mozbase/blob/master/mozprofile/mozprofile/profile. > py#L249 I guess). > Now each time I seek a Flash video (like on YouTube), the focus of Firefox > is stolen by the Flash plugin, and I can't use anymore the keyboard (in the > location bar e.g.) or the mouse wheel scrolling. I need to switch to another > application to get the focus back. > Of course, resetting focusmanager.testmode fixes the issue. > > Question: Is this interaction between focusmanager.testmode enabled and the > Flash plugin a real bug or an expected behavior? This seems a related though slightly different issue. In linux, I can't type even on non-flash pages
This sounds like bug 78414 and is not related to this issue.
> Yes, it is opened in the foreground. To reproduce, install mozrunner > (`easy_install mozrunner`, if you have easy_install available) from > http://pypi.python.org/pypi/mozrunner and run `mozrunner $(which firefox)` So when I do this the window opens up in the foreground and typing works ok. I confirmed that the testmode is enabled.
On linux?
(In reply to Neil Deakin from comment #28) > > Yes, it is opened in the foreground. To reproduce, install mozrunner > > (`easy_install mozrunner`, if you have easy_install available) from > > http://pypi.python.org/pypi/mozrunner and run `mozrunner $(which firefox)` > > So when I do this the window opens up in the foreground and typing works ok. > I confirmed that the testmode is enabled. I just tried this again myself, and am still able to replicate. Firefox 16.0.1 on Ubuntu 11.10 64bit. I did have to add the -b switch to the command though: mozrunner -b $(which firefox)
I can no longer replicate this with Firefox 20 and Ubuntu 12.04 64bit. Could you try to replicate Jeff?
Interesting, I did not notice this! WFM running 'mozrunner -b `which firefox`' here. Ubuntu 12.10. Nightly 23.0a1 (today's, probably, or recent anyway). mozrunner does indeed set this preference and indeed I am able to type. Going to close as WORKSFORME. It'd be nice to have follow up info as to why this is fixed, but for me, I'm just glad it is.
Feel free to reopen if desired. For me, seems fine ATM
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.