Closed Bug 566671 Opened 15 years ago Closed 11 years ago

onfocus/onblur are delayed until window have system focus

Categories

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

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

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: MatsPalmgren_bugz, Unassigned)

References

Details

(Keywords: html5)

onfocus/onblur are delayed until window have system focus. Spawned off from bug 564413: bug 564413 comment 2: Boris Zbarsky (:bz) 2010-05-07 06:45:55 PDT Well it makes focus() calls on elements in unfocused windows/tabs not actually fire onfocus until some later time. Is that something that will cause web compat issues? bug 564413 comment 7: Mats Palmgren [:mats] 2010-05-12 07:39:38 PDT Does onfocus fire when window does not have focus? Chrome on Linux: yes; when focusing the window it fires it twice again. Opera on Linux: yes; does not fire it again when focusing the window. Webkit nightly on OSX: yes; and fires it again when focusing the window. IE8 on XP (in VirtualBox VM): yes; and fires it again when focusing the window. So it seems we're the only UA that delay the onfocus until the window is focused. ============= After reading HTML5 8.4 Focus http://www.whatwg.org/specs/web-apps/current-work/#focus In particular, in 8.4: "Which elements within a top-level browsing context currently have focus must be independent of whether or not the top-level browsing context itself has the system focus." And in 8.4.4, the description of Element.focus(), doesn't mention any delay or requirements on the window for doing the "focusing steps", nor in 8.4.2 where the "focusing steps" are described.
This also effects users of Selenium automation tool. Using the WebDriver API, events that respond to a focus are not fired until the browser window is focused. Unfortunately it is not always possible to ensure the browser window is focused, especially when running multiple tests in parallel. This will delay WebQA migrating our automated Selenium tests to the WebDriver API, which - amongst other things - is the first step towards running our tests on mobile devices.
It would be good to have a way to do testing that allows for testing focus while running in the background. That isn't this bug, but someone might have filed another bug for it.
This issue is reproducible on Windows7 using Selenium Webdriver It causes 2 test to fail when the Firefox window doesn't have focus and to pass when the window has focus.
This has become a blocking issue for running automated selenium tests against addons.mozilla.org. Currently, we are switching all of the automated tests for amo to webdriver so that we can do testing for apps and mobile. This bug means that we will not be able to run our 100+ tests concurrently. We would switch to running the tests in Chrome or Explorer, but because the behavior of addons is quite different for obvious reasons in Firefox, any automated tests we have for addons must work in Firefox.
Neil/Dietrich: is Neil the right owner for this bug? How can we nominate it for the next train, if so? Thanks in advance (as you can see by comment 1, comment 2, comment 3, this is a pretty huge deal for our test infrastructure + reliability).
My opinion is that this bug, as described in comment 0, is invalid. Other browsers implement it inconsistently, and I think our behaviour is more useful.
Neil, could you explain why you think that it's invalid? Comment 0 has a quote from the spec that explicitly says that it should be independent from the windows' focus state. Firefox is delaying events depending on the windows' focus state. Seems like a clear contradiction to me. "and I think our behaviour is more useful". Well, that really depends on what you're doing. If you're using firefox for automated testing, this is preventing you from doing your jo, which some people consider everything but useful ;)
As I said above(In reply to Christoph Neuroth from comment #7) > Neil, could you explain why you think that it's invalid? Comment 0 has a > quote from the spec that explicitly says that it should be independent from > the windows' focus state. Firefox is delaying events depending on the > windows' focus state. Seems like a clear contradiction to me. That may be so, but it doesn't make sense to me at all to fire a focus event on something that isn't actually focused. > "and I think our behaviour is more useful". Well, that really depends on > what you're doing. If you're using firefox for automated testing, this is > preventing you from doing your jo, which some people consider everything but > useful ;) As I said above, allowing automated testing of background windows is a different bug. Fixing this bug wouldn't allow you to do automated testing either.
(In reply to Neil Deakin from comment #8) > > As I said above, allowing automated testing of background windows is a > different bug. Fixing this bug wouldn't allow you to do automated testing > either. (In reply to Neil Deakin from comment #8) > As I said above(In reply to Christoph Neuroth from comment #7) > > Neil, could you explain why you think that it's invalid? Comment 0 has a > > quote from the spec that explicitly says that it should be independent from > > the windows' focus state. Firefox is delaying events depending on the > > windows' focus state. Seems like a clear contradiction to me. > > That may be so, but it doesn't make sense to me at all to fire a focus event > on something that isn't actually focused. Currently IE and Chromium can handle this. Opera has a few quirks but these are being solved at the moment. > > > "and I think our behaviour is more useful". Well, that really depends on > > what you're doing. If you're using firefox for automated testing, this is > > preventing you from doing your jo, which some people consider everything but > > useful ;) > > As I said above, allowing automated testing of background windows is a > different bug. Fixing this bug wouldn't allow you to do automated testing > either. I have raised bug 702605
(In reply to Neil Deakin from comment #6) > I think our behaviour is more useful. Why is our current behavior more useful?
Whether our current behavior is more useful or not I don't know, but we need to do something here to enable concurrent testing with selenium and the like here. Neil, what options do we have here? Olli, any thoughts?
As Neil has said, fixing this bug wouldn't allow the kind of automatic tests Selenium is apparently trying to do. (I don't understand why browser couldn't have focus, since that is the way to get more realistic test results.) And I agree with Neil that Gecko focus handling is pretty good in this case, since it is definitely very consistent. For testing, there is bug 702605, and I'm still waiting for answers to my questions.
It's tricky if the tester is expecting to run tests in one window but have another window open which is being used for non-testing. For testing, what is effectively desired is a special mode that can be enabled in which the active window is determined and maintained internally rather than relying on the os to do so. Attempts to call nsIWidget::SetFocus are instead redirected. Any real OS focus events that occur, for example by the user raising the test window running in the background would either just be handled as normal, possibly causing the tests to fail, or just be ignored.
Yeah, having a test mode sounds good. Maybe bug 702605 is about that :)
Note also the case where a test wants to open a new window, but if the tester wants to keep the tests running in the background, the new window needs to open behind other windows.
It looks like there are some questions about the problems we're having. I'll try to clarify what we're looking for in this comment. We should have a chat about this in irc. I'm based in Mountain View and hang out mostly in #mozwebqa. Our CI runs these tests in a grid configuration, so there are 5 or more tests happening at once. Even if we run the tests sequentially, tests that have a dialog box opening will fail because the dialog box takes focus from the main window. I'm happy to demonstrate what happens in a screenshare and talk about it further. It's been a very tricky problem for us to isolate. For reference, here is the github for our webdriver tests: https://github.com/mozilla/Addon-Tests/tree/webdriver These are the tests where the problem is occurring along with a github link: TestHome.test_that_verifies_upper_menu_navigation_items https://github.com/mozilla/Addon-Tests/blob/webdriver/tests/test_homepage.py#L123 TestAmoLayout.test_other_applications_thunderbird https://github.com/mozilla/Addon-Tests/blob/webdriver/tests/test_layout.py#L49 TestAmoLayout.test_the_applications_listed_in_other_applications https://github.com/mozilla/Addon-Tests/blob/webdriver/tests/test_layout.py#L99 TestPersonas.test_the_featured_personas_section https://github.com/mozilla/Addon-Tests/blob/webdriver/tests/test_personas.py#L71 TestReviews.test_that_new_review_is_saved https://github.com/mozilla/Addon-Tests/blob/webdriver/tests/test_reviews.py#L87
Here is a screencast of the behavior: http://screencast.com/t/bcNWBRDS
Neil, should this be resolved by focusmanager.testmode? I've finally gotten around to testing this against our addons.mozilla.org tests and even with focusmanager.testmode enabled I encounter issues when mouse hovers are not firing when the browser window is not in view.
Flags: needinfo?(enndeakin)
This doesn't have anything to do with testmode nor with mouse events.
Flags: needinfo?(enndeakin)
I have raised bug 905030 to cover the mouse over events. Are the onfocus/onblur events covered by focusmanager.testmode? I'm not sure which of the Web QA suites demonstrated this issue, since I believe it was originally encountered in a suite that no longer exists (the links in comment 16 are all dead). If this is covered by the testmode then I can try to verify so we can close this bug.
Flags: needinfo?(enndeakin)
(In reply to Neil Deakin from comment #20) > This doesn't have anything to do with testmode nor with mouse events. The test mode is mentioned by yourself in comment 13, which is why I understood it to be related to this bug.
No, this bug is invalid in my opinion.
Flags: needinfo?(enndeakin)
Closing this bug as INVALID based on comment 6 and comment 23. If we still have issues automating in multiple instances using Marionette (which will replace the current FirefoxDriver from Selenium) then I think that should be raised separately.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.