Open Bug 1039867 Opened 10 years ago Updated 2 years ago

Create mochitests for more Mixed Content test cases

Categories

(Core :: DOM: Security, defect, P3)

Product:
Core
Component:
DOM: Security
Type:
defect

Tracking

()

People

(Reporter: tanvi, Unassigned, Mentored)

References

(Blocks 2 open bugs)

Details

(Keywords: good-first-bug, Whiteboard: [domsecurity-backlog3])

There are a bunch of test cases here - https://people.mozilla.org/~tvyas/AllMixedTests.html Some are in mochitests, and some are not. As part of the "Revamp Gecko Security Hooks" project we should make sure these get converted to mochitests and still pass with all of our changes.
Mentor: tanvi
Whiteboard: good first bug
Hi, Can I work on this?
Yes, sure. Please go for it. I can help out with more details and explain some of the test cases if needed.
I would like to work on this bug what should I be doing and starting steps please plus can you assign this one to me ?
Flags: needinfo?(tanvi)
(In reply to Tummala Dhanvi [:c0mrad3][UTC+5.30] from comment #3) > I would like to work on this bug > > what should I be doing and starting steps please > > plus can you assign this one to me ? There are a number of different mixed content blocker live test cases here: [1] https://people.mozilla.org/~tvyas/AllMixedTests.html Some of them are covered by mochitests that are run automatically all the time. The mixed content blocker mochitests we have are all tagged with "tags = mcb", so you can get a list of them easily here: [2] http://mxr.mozilla.org/mozilla-central/search?string=tags+%3D+mcb&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central For this bug, you have to go through each test case in [1] and see if we have a mochitest in [2] that covers that mixed content test case. If we don't create a new mochitest that reflects the behavior of the live test case. If you don't get to all of them, that is okay too. Any help getting this started would be nice. If you are up for this, I will assign you to the bug. Thanks!
Flags: needinfo?(tanvi)
This is my first bug in security Well I see a steep learning curve for this bug :) (as I googled for mixed content and mochitest) I will start working on this from next week and try to fix it. I am up for the challenge assign this to me :)
Flags: needinfo?(tanvi)
Assignee: nobody → dhanvicse
Flags: needinfo?(tanvi)
(In reply to Tummala Dhanvi [:c0mrad3][UTC+5.30] from comment #5) > This is my first bug in security > > Well I see a steep learning curve for this bug :) (as I googled for mixed > content and mochitest) > > I will start working on this from next week and try to fix it. > > I am up for the challenge assign this to me :) Yes, without knowledge of one of Mixed Content or mochitests, this will be challenging since you will need to learn about both. I would start by learning a bit about Mixed Content and understanding what the live test cases are doing. Next step will be to learn how to write mochitests.
Status: NEW → ASSIGNED
Component: Security → DOM: Security
Whiteboard: good first bug → [domsecurity-backlog], good first bug
Priority: -- → P3
Whiteboard: [domsecurity-backlog], good first bug → [domsecurity-backlog3], good first bug
(In reply to Tanvi Vyas [:tanvi] from comment #6) > (In reply to Tummala Dhanvi [:c0mrad3][UTC+5.30] from comment #5) > > This is my first bug in security > > > > Well I see a steep learning curve for this bug :) (as I googled for mixed > > content and mochitest) > > > > I will start working on this from next week and try to fix it. > > > > I am up for the challenge assign this to me :) > > Yes, without knowledge of one of Mixed Content or mochitests, this will be > challenging since you will need to learn about both. > > I would start by learning a bit about Mixed Content and understanding what > the live test cases are doing. Next step will be to learn how to write > mochitests. For now what I have understood about mixed contents is that on a page that is encrypted (https) there might me request made from http (which can be modified by an attacker) such pages are said to contain mixed (https & http) content. My next part would be to read about the mochtest and try writing few
tanvi: is there any reason not to write those tests as web-platform-tests, so we can share them?
Do you have a backup of that page since p.m.o got shut down? Could you attach it here so we could diagnose what needs to be added to wpt? If there is no backup then we should probably close unless you can remember some of the cases.
Flags: needinfo?(tanvi)
April created a backup! But I can't seem to find where it is now. April, can you provide the link? Thanks!
Flags: needinfo?(april)
I can! They are available here: https://github.com/mozilla/mixed-content-tests (the code) http://mixed-content-tests-mozilla.org/ (also over https, but no automatic redirect) Note that I've done some similar work for :jkt that is either up on badssl.com or badsite.io. I recently did a HTTPS -> Flash Object Over HTTPS -> Flash Object Requests Over HTTP mixed content test, which was pretty weird. If you make changes to the GitHub repo it should get pushed to the site periodically. Every 5 minutes or so, if I recall.
Flags: needinfo?(april)
Thanks April!
Flags: needinfo?(tanvi)

Hi, is this issue still relevant?
I can try to tackle this :)

Flags: needinfo?(tanvi)

I'm not sure what is left here. Redirecting to Jonathan.

Flags: needinfo?(tanvi) → needinfo?(jkt)

Hi Mariana,

Sorry for the delay. Yeah so this is still relevant, https://bugzilla.mozilla.org/show_bug.cgi?id=1039867#c11 outlines the tests that are still available. They need to be coded into web-platform-tests that we can automate them. As there are quite a lot I would create a patch for each test (at least to start with).

The code for mixed content web-platform-tests in firefox is stored here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/mixed-content if you check out firefox you can run these with ./mach test testing/web-platform/tests/mixed-content/img-tag/http-csp/same-host-https/top-level/no-redirect/allowed/allowed.https.html on the command line for example.

Some of the tests look like they require disabling the protection and then navigating which would likely require a mozilla only check.

A good task to start with would be to categorise them into mochitest/wpt tests based on if they need UI work. Also checking if there is already overlap with existing tests too would be helpful. From there I can help with writing the tests.

Please let me know if there is anything I can help you with :)

Thanks
Jonathan

Flags: needinfo?(jkt) → needinfo?(marian.meireles)

Hey Jonathan,
Thanks for the answer and for offering help. :)

So I'm confused about a few things... First, I'm not sure how to categorize them into mochitests or wpt tests. Mochitests are stuff that is automatically checked by the computer and wpt tests needs the interaction of an user? Would that be a good way to separate them?

Also, I was reading this article(https://developer.mozilla.org/en-US/docs/Mozilla/QA/web-platform-tests) and just to make sure, I should submit the patches here instead of the web-platform-tests github, right?

Thank you!

Flags: needinfo?(marian.meireles)

The separation is that both are very similar for use-cases. Where possible adding them as web-platform-tests is better however this is sometimes very difficult due to requiring interaction with the Browser UI.

By interaction I mean, the test will click on the shield (mixed content) icon and disable mixed content blocking, open another tab then click another link. Web platform tests can click on the content area but they are agnostic to browsers, so generally have no control over how the browser does things.

So in some of those tests there is a comment saying "click on the icon to disable", these are unlikely possible to make a web platform test without a lot of additional work. I suggest any tests that require anything other than typing an address into the URL bar should just be a mochitest.

Adding the web-platform-tests to mozilla source code will have it replicated onto github, so is likely easier here for these tests.

Sorry Jonathan, I started to classify the tests but I'm still confused about it. You said:

So in some of those tests there is a comment saying "click on the icon to disable", these are unlikely possible to make a web platform test without a lot of additional work. I suggest any tests that require anything other than typing an address into the URL bar should just be a mochitest.

Some tests like this one https://mixed-content-tests-mozilla.org/tvyas/mixeddocument4.html will show me text and won't ask me to deactivate secure connection, but it won't run the javascript code on its HTML. Here is the code for this test:

<!DOCTYPE html>
<html>
<head>
<script>
  var txt="<!DOCTYPE html><html><body>Learning about the HTML DOM is fun!</body></html>";
  document.write(txt);
  document.open();
</script>
<script src = 'http://mixed-content-tests-mozilla.org/tvyas/script1.js'></script>
</head>

<body>
Hello There
</body>
</html>

Does that means that this is a web-platform-test? That's exactly what we're testing here, right? If we're in a secure connection than the code here http://mixed-content-tests-mozilla.org/tvyas/script1.js shouldn't run.

Sorry for asking this again, I just wanted to make sure!
And thanks for being so helpful Jonathan!

Flags: needinfo?(jkt)

(In reply to Mariana Meireles from comment #18)

Does that means that this is a web-platform-test? That's exactly what we're testing here, right? If we're in a secure connection than the code here http://mixed-content-tests-mozilla.org/tvyas/script1.js shouldn't run.

Sorry for the delay. Yeah if the point is just to prevent scripts loading (I think there are some that are used this way with UI interaction though) then it's just a web platform test.

Some of these tests like this one in particular almost certainly have tests on web-platform-tests too.

All of these tests aren't unit tests, which are what we are looking for here. So for example https://mixed-content-tests-mozilla.org/tvyas/mixeddocument2.html instead of firing an alert should likely just call something to fail the test, the test should likely then wait for document load of the next page navigation.

Thank you for looking into this, having these as unit tests will ensure we are well tested on a fundamental part of the web platform.

Flags: needinfo?(jkt)
Keywords: good-first-bug
Whiteboard: [domsecurity-backlog3], good first bug → [domsecurity-backlog3]

This good-first-bug hasn't had any activity for 6 months, it is automatically unassigned.
For more information, please visit auto_nag documentation.

Assignee: dhanvicse → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.