Closed Bug 942066 Opened 7 years ago Closed 2 years ago

Use loadChromeScript and SJS for MMS mochitest.

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED WONTFIX
blocking-b2g -

People

(Reporter: ctai, Unassigned)

References

Details

Attachments

(2 files, 2 obsolete files)

In this bug, I want to make mochitest can run on chrome process in B2G emulator. Because MMS is only run on Firefox OS, the mochitest can only run on content process in B2G emulator currently. But for MMS mochitest, it needs to run on chrome process. So I need this bug for MMS mochitest.
Why does it need to run in chrome space? What is it doing that it can't achieve with specialpowers (https://developer.mozilla.org/en-US/docs/SpecialPowers)? If there is something you need that specialpowers doesn't provide, we could look into adding new API's.

As I understand it we want mochitests in content space so we can test permissions and the oop architecture, so what you are proposing is a whole new suite.
Blocks: 916356
Flags: needinfo?(ctai)
Sorry for late reply, I was absence for funeral from 11/25-28.
The reason to create this bug is below:
I want to write test cases for MMS. In this test, I will use iframe for message AP(run in content prcoess) to test OOP.
Since MMS in chrome process use 3G data to communicate with MMSC(carrier's server for MMS), I need to overwrite this part with my own codes to simulate MMSC(in SJS codes). This part is in chrome process. So the test case will run on chrome process and replace the MMS connection part. After that, the test case will test the OOP part via iframe.

Please feel free to correct me or give me some suggestions. Also I will check the specialpowers.
Thanks.
Flags: needinfo?(ctai)
Flags: needinfo?(ahalberstadt)
That may be out of the scope of specialpowers. My next question is, does this need to be a mochitest? Or is using another/creating a new harness ok as well? I vaguely remember talk of a mochitest-chrome like harness which uses marionette for b2g, though I don't know if anything is happening on that front.
Flags: needinfo?(ahalberstadt)
You also could use SpecialPowers.loadChromeScript perhaps for custom chrome script usage (this was implemented in bug 914633).
Ahal, 
Yes, I'm planning to write a new harness for this feature. Something might be called "mochitest-b2g-chrome-process".
Below is my plan:
1. Add a new type of test files called "MOCHITEST_B2G_CHROME_PROCESS_FILES" in makefile.
2. Those files will be launched in b2g remote mochitest on chrome process.

That is this bug's purpose.

(In reply to Andrew Halberstadt [:ahal] from comment #3)
> That may be out of the scope of specialpowers. My next question is, does
> this need to be a mochitest? Or is using another/creating a new harness ok
> as well? I vaguely remember talk of a mochitest-chrome like harness which
> uses marionette for b2g, though I don't know if anything is happening on
> that front.
Mwargers,
Thanks for your suggestion.
I am not sure I am right or not. Looks like loadChromeScript try to load part of chrome script.
But is this can be used when the test code in content process and try to replace the codes in chrome process on B2G emulator?
Thanks.


(In reply to Martijn Wargers [:mwargers] (QA) from comment #4)
> You also could use SpecialPowers.loadChromeScript perhaps for custom chrome
> script usage (this was implemented in bug 914633).
Yes, using loadChromeScript should allow you to load and execute an arbitrary script in the parent process, and send/receive notifications for it.
jgriffin/mwargers/ahal,
After read more examples about loadChromeScript. I have following questions.
The ChromeScript I want to be replaced is the MmsConnection part in dom/mobilemessage/src/gonk/MmsService.js.
I want to change the way of establishing MMS to connect to a host sjs file.
Those are running in chrome process.

The loadChromeScript use SimpleTest.getTestFileURL to get the URL of chrome script.
Can I get the url of MmsService.js by this way? Or do you have any suggestion?

If I can, I should add |addMessageListener| in MmsService.js to deal with the message.
This message is including the information of new connection way to redirect the connection to host SJS files.
After this replacement is done, it will call sendAsyncMessage to the mochitest file.
Then I can start the MMS test. Am I right?
Please correct me if anything wrong.
Thanks.

(In reply to Jonathan Griffin (:jgriffin) from comment #7)
> Yes, using loadChromeScript should allow you to load and execute an
> arbitrary script in the parent process, and send/receive notifications for
> it.
Flags: needinfo?(martijn.martijn)
Flags: needinfo?(jgriffin)
Flags: needinfo?(ahalberstadt)
SimpleTest.getTestFileURL is designed to work with files that are in the same directory as the test, which isn't the case here.  But, MmsService.js should be able to be loaded using resource://gre/components/MmsService.js; there's no need to use getTestFileURL.

Yes, you could add addMessageListener to MmsService.js to deal with the messages to and from the content process, or potentially you could create a test .js file that loads MmsService.js and handles the cross-process messages so that you don't need to add test code to MmsService.js.
Flags: needinfo?(jgriffin)
Flags: needinfo?(ahalberstadt)
Flags: needinfo?(martijn.martijn)
Summary: [Mochitest] [B2G] Make mochitest can run on chrome process in B2G emulator. → Use loadChromeScript and SJS for MMS mochitest.
mwargers/jgriffin/ahal,
Thanks for your suggestion about loadChromeScript. It works for me! :) Now I have some questions about how to use SJS on B2G emulator via mochitest and TBPL.
What I want is below.
1. I want the MMS mochitest can run on TBPL. Currently only b2g emulator mochitests can run on TBPL[1].	
2. SJS needs a desktop version xpcshell. So it means I need to specify xre-path for my test. But I can't find the mach options arguments about xre-path. I use ./mach help mochitest-remote[2] to find the options. So should I change the code in mochitest_options.py to support xre-path in mach arguments? Or I can leave those settings to TBPL?
3. Once my mochitest is done, is this means I only need to use "try: -b do -p emulator -u mochitest -t none" to run and MMS mochitest on TBPL(including SJS, desktop xpcshell, TBPL can automatically handle those settings)?

Thanks again.
[1]: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Test_Execution_Chart?redirectlocale=en-US&redirectslug=Mozilla%2FFirefox_OS%2FPlatform%2FTesting%2FTest_Execution_Chart
[2]: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Mochitests


(In reply to Jonathan Griffin (:jgriffin) from comment #9)
> SimpleTest.getTestFileURL is designed to work with files that are in the
> same directory as the test, which isn't the case here.  But, MmsService.js
> should be able to be loaded using resource://gre/components/MmsService.js;
> there's no need to use getTestFileURL.
> 
> Yes, you could add addMessageListener to MmsService.js to deal with the
> messages to and from the content process, or potentially you could create a
> test .js file that loads MmsService.js and handles the cross-process
> messages so that you don't need to add test code to MmsService.js.
Flags: needinfo?(martijn.martijn)
Flags: needinfo?(jgriffin)
Flags: needinfo?(ahalberstadt)
(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #10)
> 1. I want the MMS mochitest can run on TBPL. Currently only b2g emulator
> mochitests can run on TBPL[1].

Is the MMS mochitest just part of mochitest-plain? To get it running on the emulator, you just need to add it to testing/mochitest/b2g.json.

> 2. SJS needs a desktop version xpcshell. So it means I need to specify
> xre-path for my test. But I can't find the mach options arguments about
> xre-path. I use ./mach help mochitest-remote[2] to find the options. So
> should I change the code in mochitest_options.py to support xre-path in mach
> arguments? Or I can leave those settings to TBPL?

There's no option because mach handles it for you (it uses the copy of xulrunner that gets downloaded as part of the gaia build). Similarly, the TBPL automation handles it for you so no need to worry about it.

> 3. Once my mochitest is done, is this means I only need to use "try: -b do
> -p emulator -u mochitest -t none" to run and MMS mochitest on TBPL(including
> SJS, desktop xpcshell, TBPL can automatically handle those settings)?

Correct. Though it's good form to only run the specific chunk(s) (e.g -u mochitest-2) that the MMS tests end up getting run in.
 
> Thanks again.
No problem, glad to help :)
Flags: needinfo?(ahalberstadt)
Thanks for your quick respond.
For 1, yes, MMS mochitest will be part of mochitest-plain. I will try to add it to testing/mochitest/b2g.json.

For 2, I have further question. The SJS file which I wrote is not be able to run on xulrunner version. It can only work on desktop version xpcshell. Is there anything I missed? For my understanding, emulator mochitest need a desktop version xpcshell. "You need to have a desktop version of xpcshell (it needs to run on the host); you have this already if you have a copy of Firefox on your system. " quoted form [1]. In my memory, xulrunner is not a desktop version xpcshell. Am I right?

For 3. I will try later. :)

[1]: https://developer.mozilla.org/en-US/Firefox_OS/Platform/Automated_testing/Mochitests?redirectlocale=en-US&redirectslug=Mozilla%2FFirefox_OS%2FPlatform%2FTesting%2FMochitests

(In reply to Andrew Halberstadt [:ahal] from comment #11)
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #10)
> > 1. I want the MMS mochitest can run on TBPL. Currently only b2g emulator
> > mochitests can run on TBPL[1].
> 
> Is the MMS mochitest just part of mochitest-plain? To get it running on the
> emulator, you just need to add it to testing/mochitest/b2g.json.
> 
> > 2. SJS needs a desktop version xpcshell. So it means I need to specify
> > xre-path for my test. But I can't find the mach options arguments about
> > xre-path. I use ./mach help mochitest-remote[2] to find the options. So
> > should I change the code in mochitest_options.py to support xre-path in mach
> > arguments? Or I can leave those settings to TBPL?
> 
> There's no option because mach handles it for you (it uses the copy of
> xulrunner that gets downloaded as part of the gaia build). Similarly, the
> TBPL automation handles it for you so no need to worry about it.
> 
> > 3. Once my mochitest is done, is this means I only need to use "try: -b do
> > -p emulator -u mochitest -t none" to run and MMS mochitest on TBPL(including
> > SJS, desktop xpcshell, TBPL can automatically handle those settings)?
> 
> Correct. Though it's good form to only run the specific chunk(s) (e.g -u
> mochitest-2) that the MMS tests end up getting run in.
>  
> > Thanks again.
> No problem, glad to help :)
Flags: needinfo?(martijn.martijn)
Flags: needinfo?(jgriffin)
(In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> For 2, I have further question. The SJS file which I wrote is not be able to
> run on xulrunner version. It can only work on desktop version xpcshell. Is
> there anything I missed? For my understanding, emulator mochitest need a
> desktop version xpcshell. "You need to have a desktop version of xpcshell
> (it needs to run on the host); you have this already if you have a copy of
> Firefox on your system. " quoted form [1]. In my memory, xulrunner is not a
> desktop version xpcshell. Am I right?

I'm pretty sure xulrunner uses the same xpcshell binaries that Firefox does. What we really meant by "desktop xpcshell" was a non-arm compiled binary :).

One easy way to test would be to pass in --xre-path gaia/xulrunner-sdk-26/xulrunner-sdk/bin
Do yo mean use gaia/xulrunner-sdk-26/xulrunner-sdk/bin/xpcshell to execute the SJS file which I wrote?


(In reply to Andrew Halberstadt [:ahal] from comment #13)
> (In reply to Chia-hung Tai [:ctai :ctai_mozilla :cht] from comment #12)
> > For 2, I have further question. The SJS file which I wrote is not be able to
> > run on xulrunner version. It can only work on desktop version xpcshell. Is
> > there anything I missed? For my understanding, emulator mochitest need a
> > desktop version xpcshell. "You need to have a desktop version of xpcshell
> > (it needs to run on the host); you have this already if you have a copy of
> > Firefox on your system. " quoted form [1]. In my memory, xulrunner is not a
> > desktop version xpcshell. Am I right?
> 
> I'm pretty sure xulrunner uses the same xpcshell binaries that Firefox does.
> What we really meant by "desktop xpcshell" was a non-arm compiled binary :).
> 
> One easy way to test would be to pass in --xre-path
> gaia/xulrunner-sdk-26/xulrunner-sdk/bin
Yeah. If it doesn't work it's possible that we need to update the copy used to a later version (similarly for tbpl).
For the record, there are a lot of B2G mochitests executing SJS files with that binary at the moment.
Okay, I guess I know what's going wrong. I guess my SJS file needs the modification of my patch for gecko codes. So the copy in xulrunner might not be able to run this SJS. Am I right? So I can manually replace the xpcshell in gaia/xulrunner-sdk-26/xulrunner-sdk/bin with the built xpcshell from my desktop build for my local test purpose. In the mochitests on TBPL, the automation is done those kind of jobs. Sounds pretty cool. Thank you.
No problem. Yes, you can replace the xpcshell for testing purposes, but to get this in production we'll need to do two things:

1) Update the version gaia uses to a gecko containing your changes by modifying: https://github.com/mozilla-b2g/gaia/blob/master/Makefile#L542

2) Update the version tbpl uses by creating an xre.zip similar to http://people.mozilla.com/~ahalberstadt/getb2g/xre.zip and filing a bug under Release Engineering/General Automation to update the xre.zip in tooltool.
Attached patch WIP-bug-942066-1.patch (obsolete) — Splinter Review
This is a WIP patch.
Attached patch WIP-bug-942066-2.patch (obsolete) — Splinter Review
This is a WIP patch.
Attachment #8350438 - Attachment description: bug-942066-2.patch → WIP-bug-942066-2.patch
Assignee: ctai → btseng
This is a WIP workaround to enable MMS connection during Mochitest. Will be revised after bug#871475(B2G Emulator: support RIL data connection emulation) is ready.
Attachment #8350437 - Attachment is obsolete: true
This is a WIP patch to support verifying MmsService via Mochitest.
Attachment #8350438 - Attachment is obsolete: true
Attachment #8364979 - Attachment description: WIP Part 1 v2: Add Mochitest Test Framework for MMS → WIP Part 2 v2: Add Mochitest Test Framework for MMS
Comment on attachment 8364979 [details] [diff] [review]
WIP Part 2 v2: Add Mochitest Test Framework for MMS

Hi Gene, Vicamo,

I've refined the Mochitest cases of MMS(Still WIP) as attached and 
would like to see if you have better suggestion/comment for current implementation.

In addition, I'd like to outline the patch at the end of this comment for better understanding before you review it.

Thanks for your time to review it. :)

Bevis
--
Outline:
1. New MMS Mochitest files are located in dom/mobilemessage/tests/mochitest/ and separated into 3 parts:
   - test cases:
     ├── test_mms_receive.html:         Single test case for auto retrieving mms.
     ├── test_mms_receive_manual.html:  Single test case for manually retrieving mms.
     └── test_mms_send.html:            TestSuite for sending MMS, and receiving positive/negative deliver/read reports.
   - support file to control MmsService in chrome process:
     └── mms_chrome_helper.js
   - sjs files to simulate MMSC:
     ├── mmsc_receive_manual.sjs:       MMSC for test_mms_receive.html
     ├── mmsc_receive.sjs:              MMSC for test_mms_receive_manual.html
     └── mmsc_send.sjs:                 MMSC for test_mms_send.html
   - helper js files for mmsc:
     ├── mmsc_request_helper.js:        Helper for parsing/composing the MMS per HTTP request.
     └── mms_pdu_helper.js              Helper to combine MmsPduHelper.jsm/WspPduHelper.jsm for MMSC to use without expose them into XRE.
   - manifest of this mochitest
     └── mochitest.ini
2. Misc modified files:
   - TODO: move both mms/sms mochitest into dom/mobilemessage/tests/mochitest/
     ├── dom/mobilemessage/tests/moz.build
     └── dom/mobilemessage/tests/xpcshell.ini
   - To support encoding of Content-location in M-Notification.ind composed by mms_chrome_helper.js.
     ├── MmsPduHelper.jsm
     └── WspPduHelper.jsm
3. TODO:
   - Replace workaround in comment#21 with the solution in bug#871475.
   - See if there is any possibility to verify the sending of delivery/read reports in MMSC side.
Attachment #8364979 - Flags: feedback?(vyang)
Attachment #8364979 - Flags: feedback?(gene.lian)
Attachment #8364979 - Flags: feedback?(vyang)
Attachment #8364979 - Flags: feedback?(gene.lian)
Component: Mochitest → RIL
Product: Testing → Firefox OS
blocking-b2g: --- → backlog
blocking-b2g: backlog → -
no longer following up this bug.
Assignee: btseng → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.