Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Description • 11 years ago

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.

	Andrew Halberstadt [:ahal]
	Comment 1 • 11 years ago

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.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 2 • 11 years ago

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.

	Andrew Halberstadt [:ahal]
	Comment 3 • 11 years ago

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.

	Martijn Wargers (dead)
	Comment 4 • 11 years ago

You also could use SpecialPowers.loadChromeScript perhaps for custom chrome script usage (this was implemented in bug 914633).

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 5 • 11 years ago

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.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 6 • 11 years ago

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

	Jonathan Griffin (:jgriffin)
	Comment 7 • 11 years ago

Yes, using loadChromeScript should allow you to load and execute an arbitrary script in the parent process, and send/receive notifications for it.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 8 • 11 years ago

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.

	Jonathan Griffin (:jgriffin)
	Comment 9 • 11 years ago

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.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 10 • 11 years ago

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.

	Andrew Halberstadt [:ahal]
	Comment 11 • 11 years ago

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

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 12 • 11 years ago

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 :)

	Andrew Halberstadt [:ahal]
	Comment 13 • 11 years ago

(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

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 14 • 11 years ago

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

	Andrew Halberstadt [:ahal]
	Comment 15 • 11 years ago

Yeah. If it doesn't work it's possible that we need to update the copy used to a later version (similarly for tbpl).

	Andrew Halberstadt [:ahal]
	Comment 16 • 11 years ago

For the record, there are a lot of B2G mochitests executing SJS files with that binary at the moment.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 17 • 11 years ago

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.

	Andrew Halberstadt [:ahal]
	Comment 18 • 11 years ago

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.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 19 • 11 years ago

This is a WIP patch.

	Chia-hung Tai [:ctai :ctai_mozilla :cht] Reporter
	Comment 20 • 11 years ago

This is a WIP patch.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 21 • 11 years ago

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.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 22 • 11 years ago

This is a WIP patch to support verifying MmsService via Mochitest.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 23 • 11 years ago

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.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 24 • 9 years ago

no longer following up this bug.

	BMO Automation
	Comment 25 • 7 years ago

Firefox OS is not being worked on