1332064 - Intermittent testing/marionette/harness/marionette_harness/tests/unit/test_navigation.py TestNavigate.test_focus_after_navigation | NoSuchElementException: Unable to locate element: :focus

Status: RESOLVED FIXED

(Testing :: Marionette Client and Harness, defect, P2)

Description

[Treeherder Bug Filer]

Filed by: philringnalda [at] gmail.com

https://treeherder.mozilla.org/logviewer.html#?job_id=70077307&repo=autoland

https://archive.mozilla.org/pub/firefox/tinderbox-builds/autoland-win64/1484756427/autoland_win8_64_test-marionette-e10s-bm127-tests1-windows-build116.txt.gz

Comment 1

[Intermittent Failures Robot]

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

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

[Intermittent Failures Robot]

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

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

NI myself to disable this test on ESR52 next time I'm pushing there.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The patch on bug 1291320 didn't land on esr52, so there is no need to get it disabled on this branch.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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?

Comment 8

[Ryan VanderMeulen [:RyanVM]]

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

Comment 9

[Andreas Tolfsen ❲:ato❳]

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?

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(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).

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/91b9196bdac8

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With bug 1398111 fixed for even Firefox 63 we should be able to re-enable this test.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d0468a9962955f0cf07bb380357f4be6ec3de02a

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: Bug 1332064 - [marionette] Re-enable test_navigation.py:test_focus_after_navigation. r?jgraham

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bbbe9f2515ef
[marionette] Re-enable test_navigation.py:test_focus_after_navigation. r=jgraham

Comment 17

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/bbbe9f2515ef

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d525167ebef7

Comment 19

[Intermittent Failures Robot]

1 failures in 5197 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-esr68: 1

Platform breakdown:

• linux32-shippable: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?bug=1332064&startday=2019-06-03&endday=2019-06-09&tree=all

Comment 20

[BMO Automation]

Moving bug to Testing::Marionette Client and Harness component per bug 1815831.