Intermittent test_navigation.py TestNavigate.test_focus_after_navigation | NoSuchElementException: Unable to locate element: :focus

NEW
Unassigned

Status

Testing
Marionette
P5
normal
2 years ago
5 months ago

People

(Reporter: Treeherder Bug Filer, Unassigned)

Tracking

({intermittent-failure, leave-open, test-disabled})

Version 3
intermittent-failure, leave-open, test-disabled
Points:
---

Firefox Tracking Flags

(firefox-esr52 disabled, firefox53 disabled, firefox54 disabled, firefox55 disabled)

Details

Comment 1

a year ago
6 failures in 812 pushes (0.007 failures/push) were associated with this bug in the last 7 days.  
Repository breakdown:
* mozilla-esr52: 3
* mozilla-beta: 3

Platform breakdown:
* linux64: 4
* linux32: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332064&startday=2017-02-20&endday=2017-02-26&tree=all
It looks like that my changes on bug 1291320 are causing this failure to happen more often. I will have to check that.

Comment 3

a year ago
6 failures in 845 pushes (0.007 failures/push) were associated with this bug in the last 7 days.   

Repository breakdown:
* autoland: 4
* mozilla-esr52: 2

Platform breakdown:
* linux64: 4
* linux32: 2

For more details, see:
https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332064&startday=2017-03-27&endday=2017-04-02&tree=all
As discussed with Andreas on IRC I'm going to disable this test so we can get the patch on bug 1291320 landed. I will investigate that afterward.
Blocks: 1291320
NI myself to disable this test on ESR52 next time I'm pushing there.
Flags: needinfo?(ryanvm)
The patch on bug 1291320 didn't land on esr52, so there is no need to get it disabled on this branch.
status-firefox53: --- → disabled
status-firefox54: --- → disabled
status-firefox55: --- → disabled
status-firefox-esr52: --- → unaffected
Flags: needinfo?(ryanvm)
When I run this test locally I can force this failure by switching away from the browser window when the page gets loaded. Looks like that Firefox doesn't keep the focus in the input box, because it looses focus itself?

Andreas, right now we restart Firefox to force a focus call to the content. I wonder if this is really necessary, given that we can also create a new session without a restart. In such a case we could blur the current focus, or set it somewhere else, then restart the session, and do the normal check.

For me this would have the same affect, and would speed up the test by factor 5 (~5s -> ~1s). 

Or did I read bug 1328676 not closely enough?
Flags: needinfo?(ato)
These failures are happening on ESR52. Can you please clarify the removal of my NI to disable?
https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-esr52&job_id=93060137&lineNumber=1790
Flags: needinfo?(hskupin)
Just for context, the test that is failing here is this:

>     @skip("Bug 1332064 - NoSuchElementException: Unable to locate element: :focus")
>     @run_if_manage_instance("Only runnable if Marionette manages the instance")
>     @skip_if_mobile("Bug 1322993 - Missing temporary folder")
>     def test_focus_after_navigation(self):
>         self.marionette.quit()
>         self.marionette.start_session()
> 
>         self.marionette.navigate(inline("<input autofocus>"))
>         focus_el = self.marionette.find_element(By.CSS_SELECTOR, ":focus")
>         self.assertEqual(self.marionette.get_active_element(), focus_el)

I think Henrik’s theory that the test fails because the browser itself looses focus could be true.

The intention of https://bugzilla.mozilla.org/show_bug.cgi?id=1328676 is to ensure the viewport/browser content gets focus after Firefox starts.  Without the patch, the urlbar gains focus.

(In reply to Henrik Skupin (:whimboo) from comment #7)
> Andreas, right now we restart Firefox to force a focus call to the content.
> I wonder if this is really necessary, given that we can also create a new
> session without a restart. In such a case we could blur the current focus,
> or set it somewhere else, then restart the session, and do the normal check.

Just ending the session and creating a new one, without restarting Firefox, I believe doesn’t recreate the issue the patch was trying to fix.  The issue was that the URL bar gains focus when Firefox starts.  To recreate that situation, we need to ensure the urlbar has focus before the test.

> For me this would have the same affect, and would speed up the test by
> factor 5 (~5s -> ~1s). 

If the problem here is that the test takes too long to execute, although I didn’t think that was the problem, we could potentially switch to chrome context and focus urlbar, end the session, start a session and check the focus.

However, I don’t know if that will cause the _browser window_ itself to have focus.  It sounds as if we could add a step to the test to ensure the browser window is in focus before running the test?  I don’t know from the top of my head what the correct XUL call for doing that is, but I’m sure it’s possible to request the Firefox window to be brought into focus somehow.

Does this help?
Flags: needinfo?(ato)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)
> These failures are happening on ESR52. Can you please clarify the removal of
> my NI to disable?
> https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-
> esr52&job_id=93060137&lineNumber=1790

Feel free to disable if you want that. But actually I do not really see a reason for it to do on the mozilla-esr52 branch. The number of failures is very very low:

https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1332064&startday=2017-03-27&endday=2017-04-26&tree=mozilla-esr52

We disabled the test on the other branches only, because the referenced patch triggered this way more often.
Flags: needinfo?(hskupin)
(In reply to Andreas Tolfsen ‹:ato› from comment #9)
> Just ending the session and creating a new one, without restarting Firefox,
> I believe doesn’t recreate the issue the patch was trying to fix.  The issue
> was that the URL bar gains focus when Firefox starts.  To recreate that
> situation, we need to ensure the urlbar has focus before the test.

Yeah, that was my intention to do here. 

> > For me this would have the same affect, and would speed up the test by
> > factor 5 (~5s -> ~1s). 
> 
> If the problem here is that the test takes too long to execute, although I
> didn’t think that was the problem, we could potentially switch to chrome
> context and focus urlbar, end the session, start a session and check the
> focus.

I noticed the slowness when I run this test repeatedly over 50 times to get the failure reproduced. It's simply annoying.

> However, I don’t know if that will cause the _browser window_ itself to have
> focus.  It sounds as if we could add a step to the test to ensure the
> browser window is in focus before running the test?  I don’t know from the
> top of my head what the correct XUL call for doing that is, but I’m sure
> it’s possible to request the Firefox window to be brought into focus somehow.

I will have a look at this. If it works we can also fix the other test failures which are relying on the focus (tests which utilize the popups).
Keywords: leave-open
Keywords: test-disabled
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.