Closed Bug 771224 Opened 12 years ago Closed 12 years ago

chrome marionette unit tests cause failure

Categories

(Remote Protocol :: Marionette, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla16

People

(Reporter: mdas, Assigned: mdas)

References

(Depends on 1 open bug)

Details

Attachments

(1 file)

I'm getting these errors after running browser testing suites that involve chrome commands:
 
test_child_elements (test_findelement.TestElementsChrome) ... ERROR
test_class_name (test_findelement.TestElementsChrome) ... ERROR
test_id (test_findelement.TestElementsChrome) ... ERROR
test_not_found (test_findelement.TestElementsChrome) ... ERROR
test_tag_name (test_findelement.TestElementsChrome) ... ERROR
test_timeout (test_findelement.TestElementsChrome) ... ERROR
test_xpath (test_findelement.TestElementsChrome) ... ERROR

======================================================================
ERROR: test_child_element (test_findelement.TestElementsChrome)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/tests/unit/test_findelement.py", line 152, in test_child_element
    el = self.marionette.find_element("id", "textInput")
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/marionette.py", line 366, in find_element
    response = self._send_message('findElement', 'value', **kwargs)
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/marionette.py", line 131, in _send_message
    response = self.client.send(message)
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/client.py", line 85, in send
    response = self.receive()
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/client.py", line 52, in receive
    raise MarionetteException("Could not successfully complete transport of message to Gecko, socket closed?")
MarionetteException: Could not successfully complete transport of message to Gecko, socket closed?

======================================================================
ERROR: test_child_element (test_findelement.TestElementsChrome)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/tests/unit/test_findelement.py", line 140, in tearDown
    self.marionette.execute_script("window.close();")
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/marionette.py", line 347, in execute_script
    specialPowers=special_powers)
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/marionette.py", line 131, in _send_message
    response = self.client.send(message)
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/client.py", line 85, in send
    response = self.receive()
  File "/Users/mdas/Code/mozilla-central/testing/marionette/client/marionette/client.py", line 44, in receive
    response = self.sock.recv(10)
error: [Errno 54] Connection reset by peer

==============================================

Which is not so good. Running content tests seem to be fine.
Instead of using remote xul, I added the test xul files to marionette's chrome:// urls, but only if testing is enabled.

Tested this and it works locally.
Attachment #641192 - Flags: review?(jgriffin)
Comment on attachment 641192 [details] [diff] [review]
Use chrome:// urls instead of remote xul

Review of attachment 641192 [details] [diff] [review]:
-----------------------------------------------------------------

Cool, that was easy!  We should add a note to bug 771354 when this lands, so that no one tries to reproduce that problem with one of these test cases.

::: testing/marionette/Makefile.in
@@ +16,5 @@
>  endif
>  
> +ifdef ENABLE_TESTS
> +    DEFINES += -DENABLE_TESTS
> +endif

This doesn't make sense to me, do we really need this?

::: testing/marionette/jar.mn
@@ +14,5 @@
>    content/ChromeUtils.js  (ChromeUtils.js)
> +#ifdef ENABLE_TESTS
> +  content/test.xul  (client/marionette/www/test.xul)
> +  content/test2.xul  (client/marionette/www/test2.xul)
> +  content/test_nested_iframe.xul  (client/marionette/www/test_nested_iframe.xul)

I am thinking we should move these files from 'www' (which are served by the webserver) to a new directory, /chrome, in order to provide separation for different classes of files.
Attachment #641192 - Flags: review?(jgriffin) → review+
(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> Comment on attachment 641192 [details] [diff] [review]
> Use chrome:// urls instead of remote xul
> 
> Review of attachment 641192 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Cool, that was easy!  We should add a note to bug 771354 when this lands, so
> that no one tries to reproduce that problem with one of these test cases.

Will do!

> 
> ::: testing/marionette/Makefile.in
> @@ +16,5 @@
> >  endif
> >  
> > +ifdef ENABLE_TESTS
> > +    DEFINES += -DENABLE_TESTS
> > +endif
> 
> This doesn't make sense to me, do we really need this?

Unfortunately, yes:( ENABLE_TESTS is a build variable, not a preprocessor variable. For it to be referenced in the preprocessing of a jar.mn file, you have to assign it this way.

> 
> ::: testing/marionette/jar.mn
> @@ +14,5 @@
> >    content/ChromeUtils.js  (ChromeUtils.js)
> > +#ifdef ENABLE_TESTS
> > +  content/test.xul  (client/marionette/www/test.xul)
> > +  content/test2.xul  (client/marionette/www/test2.xul)
> > +  content/test_nested_iframe.xul  (client/marionette/www/test_nested_iframe.xul)
> 
> I am thinking we should move these files from 'www' (which are served by the
> webserver) to a new directory, /chrome, in order to provide separation for
> different classes of files.

Cool, I'll get that done and push the patch
> > 
> > ::: testing/marionette/Makefile.in
> > @@ +16,5 @@
> > >  endif
> > >  
> > > +ifdef ENABLE_TESTS
> > > +    DEFINES += -DENABLE_TESTS
> > > +endif
> > 
> > This doesn't make sense to me, do we really need this?
> 
> Unfortunately, yes:( ENABLE_TESTS is a build variable, not a preprocessor 
> variable. For it to be referenced in the preprocessing of a jar.mn file, you have 
> to assign it this way.

Cool, thanks for the explanation.  I never realized the preprocessor variables were separate from the build defines.
https://hg.mozilla.org/mozilla-central/rev/ed4888197cb5
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
Depends on: 1344267
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: