Closed Bug 1038864 Opened 10 years ago Closed 10 years ago

Marionette find element fails on social chat component

Categories

(Remote Protocol :: Marionette, defect, P1)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla34

People

(Reporter: aoprea, Assigned: mdas)

Details

(Whiteboard: [affects=loop])

Attachments

(1 file, 5 obsolete files)

The component is part of Loop conversation window (the popup that appears when you receive a call). The markup is here [0].
You can select it in the browser toolbox console using $('chatbox')

When I use find_element("tag name", "chatbox") it does not fail with a NoSuchElementException but calling switch_to_frame on the return value fails with NoSuchFrameException: Unable to locate frame: undefined

[0] http://dxr.mozilla.org/mozilla-central/source/browser/base/content/socialchat.xml#8
Priority: -- → P1
Whiteboard: [affects=loop]
Marking P1 since this blocks testing
shouldn't it be find_element('id', 'chatbox') ?
(In reply to Andrei Oprea [:andreio] from comment #0)
> The component is part of Loop conversation window (the popup that appears
> when you receive a call). The markup is here [0].
> You can select it in the browser toolbox console using $('chatbox')
> 
> When I use find_element("tag name", "chatbox") it does not fail with a
> NoSuchElementException but calling switch_to_frame on the return value fails
> with NoSuchFrameException: Unable to locate frame: undefined
> 
> [0]
> http://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> socialchat.xml#8

Can you post the STR here and the link to the xul?
(In reply to Zac C (:zac) from comment #2)
> shouldn't it be find_element('id', 'chatbox') ?

I think you're right, andreio, can you verify?
chatbox is the actual tag name, so the line andrei quoted should work.  That said, it looks like the first one should have an id of "chatter", so it's conceivable that that could be a workaround:

http://dxr.mozilla.org/mozilla-central/source/browser/base/content/chatWindow.xul#165
(In reply to Malini Das [:mdas] from comment #3)
> (In reply to Andrei Oprea [:andreio] from comment #0)
> > The component is part of Loop conversation window (the popup that appears
> > when you receive a call). The markup is here [0].
> > You can select it in the browser toolbox console using $('chatbox')
> > 
> > When I use find_element("tag name", "chatbox") it does not fail with a
> > NoSuchElementException but calling switch_to_frame on the return value fails
> > with NoSuchFrameException: Unable to locate frame: undefined
> > 
> > [0]
> > http://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> > socialchat.xml#8
> 
> Can you post the STR here and the link to the xul?

You would need:
* My branch of gecko-dev/end-to-end-call https://github.com/piatra/gecko-dev/tree/end-to-end-call
* Loop Server github.com/mozilla-services/loop-server with this diff http://pastebin.mozilla.org/5568978

Run `make runserver` in loop-server directory & in gecko-dev/browser/components/loop/standalone

Run the test ./mach marionette-test browser/components/loop/test/functional

Tried selecting #chatbox & #chatter but that did not work either.
Please use tag 0.5.0 of loop-server, that is the same one I used
(In reply to Andrei Oprea [:andreio] from comment #6)
> (In reply to Malini Das [:mdas] from comment #3)
> > (In reply to Andrei Oprea [:andreio] from comment #0)
> > > The component is part of Loop conversation window (the popup that appears
> > > when you receive a call). The markup is here [0].
> > > You can select it in the browser toolbox console using $('chatbox')
> > > 
> > > When I use find_element("tag name", "chatbox") it does not fail with a
> > > NoSuchElementException but calling switch_to_frame on the return value fails
> > > with NoSuchFrameException: Unable to locate frame: undefined
> > > 
> > > [0]
> > > http://dxr.mozilla.org/mozilla-central/source/browser/base/content/
> > > socialchat.xml#8
> > 
> > Can you post the STR here and the link to the xul?
> 
> You would need:
> * My branch of gecko-dev/end-to-end-call
> https://github.com/piatra/gecko-dev/tree/end-to-end-call
> * Loop Server github.com/mozilla-services/loop-server with this diff
> http://pastebin.mozilla.org/5568978
> 
> Run `make runserver` in loop-server directory & in
> gecko-dev/browser/components/loop/standalone


When I call 'make runserver' in both loop-server and in the standalone dir in gecko-dev, I get:
[mdas@Malinis-MacBook-Pro standalone]$ make runserver

module.js:340
    throw err;
          ^
Error: Cannot find module 'express'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/Users/mdas/Code/piatra_gecko/browser/components/loop/standalone/server.js:5:15)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
make: *** [runserver] Error 8

What's missing?
"make install" for loop-server

and

"make config" in the standalone/ dir

In theory, this should be documented in the READMEs, but it may well not be.
Update:

I got this running locally with Andrei's help and after inspection, it seems like we need to add support for anonymous content (https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content), and I'll be investigating how to do that.
David, there are two things at hand here 1) we don't have a Marionette/Webdriver API to retrieve anonymous elements, but we can use execute_script to return them, and 2) we need to switch into 'xul:browser' objects.

for 1) I think that we can rely on calls like execute_script("return document.getAnonymousElementByAttribute(arguments[0], 'class', 'chat-frame');", [chatbox]) to retrieve anonymous elements in the mean time, until we figure out what to do with anonymous elements at a webdriver level

for 2) the problem is that we assume 'frame' means 'iframe' in chrome. In this case, we need to retrieve a "child" xul:browser anonymous content element, and switch to it. I tested it locally, and after switching, I was able to interact with it as expected, ie: getting the url, etc.

I'm asking for feedback to make sure I'm not missing anything with this approach.

Testing on try to see if it breaks any tests:
https://tbpl.mozilla.org/?tree=Try&rev=e8b9369e73e5
Attachment #8460546 - Flags: feedback?(dburns)
Comment on attachment 8460546 [details] [diff] [review]
add support for xul:browser elements

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

I think this approach sounds sane.

I think that long term we will want add a special case to http://dxr.mozilla.org/mozilla-central/source/testing/marionette/marionette-elements.js for anonymous node searching. This is going to be needed as part of the Mozmill transition to Marionette
Attachment #8460546 - Flags: feedback?(dburns) → feedback+
Attached patch patch with tests (obsolete) — Splinter Review
Will r? once tests pass:

desktop:
https://tbpl.mozilla.org/?tree=Try&rev=1149e848978d

b2g emulator:
https://tbpl.mozilla.org/?tree=Try&rev=c1d2528f7d2c

and I filed Bug 1043325 for dealing with finding anonymous content
Attachment #8460546 - Attachment is obsolete: true
Attached patch anonymousContent with test (obsolete) — Splinter Review
I previously applied my changes to the wrong patch. Retrying:

desktop:
https://tbpl.mozilla.org/?tree=Try&rev=f5e7ef1a1f4e

emulator:
https://tbpl.mozilla.org/?tree=Try&rev=311c84cae363
Attachment #8461572 - Attachment is obsolete: true
Comment on attachment 8461651 [details] [diff] [review]
anonymousContent with test

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

::: testing/marionette/client/marionette/chrome/test_anonymous_content.xul
@@ +19,5 @@
> +                   type="content"/>
> +      </content>
> +    </binding>
> +  </bindings>
> +  <hbox id="container" style="-moz-binding: url('#testBingings');"/>

The typo in the CSS here should cause the test to fail.  This makes me wonder if any green try results are false positives, or if I'm misunderstanding something.
Attached patch anonymousContent with test (obsolete) — Splinter Review
Heh, thanks for noticing that! Thankfully the try attempts consistently fail so there isn't anything mysterious going on. I tested this locally on a newly clobbered build and I can confirm this fixes the problem.

Updating try:
desktop:
https://tbpl.mozilla.org/?tree=Try&rev=e3ed57a2fbbe

emulator:
https://tbpl.mozilla.org/?tree=Try&rev=1a9b643afdee
Attachment #8461651 - Attachment is obsolete: true
Attached patch anonymousContent with test (obsolete) — Splinter Review
Previous tries failed because the new .xul file wasn't listed in the jar.mn. Updated the patch and I'll push to try when possible. I've been getting issues pushing to try, and I've raised them in #releng.
Attachment #8461749 - Attachment is obsolete: true
Comment on attachment 8463422 [details] [diff] [review]
anonymousContent with test

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

looking good on try
Attachment #8463422 - Flags: review?(dburns)
Comment on attachment 8463422 [details] [diff] [review]
anonymousContent with test

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

r+ with an update to the test to make it more future proof

::: testing/marionette/client/marionette/tests/unit/test_switch_anonymous_content.py
@@ +23,5 @@
> +    def test_switch(self):
> +        anon_browser_el = self.marionette.find_element("id", "browser")
> +        self.assertTrue("test_anonymous_content.xul" in self.marionette.get_url())
> +        self.marionette.switch_to_frame(anon_browser_el)
> +        self.assertTrue("test.xul" in self.marionette.get_url())

Instead of checking the URL, because we should be returning the top level browser context, can we check that we can find an element on this xul document?
Attachment #8463422 - Flags: review?(dburns) → review+
discussed offline: the xul pages are loaded in their own windows, so we do return the top level browser content, but I've also added the element check in this patch

moving r+ forward
Attachment #8463422 - Attachment is obsolete: true
Attachment #8463621 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/96e3358c2d20
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
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: