The default bug view has changed. See this FAQ.

Write tests for document.domain

RESOLVED FIXED in mozilla16

Status

()

Core
DOM: Core & HTML
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: mounir, Assigned: mounir)

Tracking

Trunk
mozilla16
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

Attachments

(1 attachment, 2 obsolete attachments)

Comment hidden (empty)
(Assignee)

Comment 1

7 years ago
Created attachment 482208 [details] [diff] [review]
Tests
Attachment #482208 - Flags: review?(jst)
(Assignee)

Comment 2

7 years ago
FWIW, these tests are no longer working.
We'll need this test when mrbkap works on further document.domain related changes for beta8, so marking a blocker.
blocking2.0: --- → beta8+
We don't need to worry about this for beta8, pushing to beta9.
blocking2.0: beta8+ → beta9+

Comment 5

6 years ago
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if  you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
(Assignee)

Comment 6

6 years ago
Re-setting the CC list assuming this change wasn't intentional.

Comment 7

6 years ago
Fixing fields my automated script accidentally blanked. Apologies for the bugspam

Updated

6 years ago
Whiteboard: hardblocker

Updated

6 years ago
Whiteboard: hardblocker → [hardblocker]
I'm keeping this as a blocker because I believe in test driven development yatta yatta, but tests don't need permission for approval so I question whether or not this even needs soft blocking status.

It needs to be done, absolutely, but does it need to keep us from shipping? I assert not!
Whiteboard: [hardblocker] → [softblocker]
(Assignee)

Comment 9

6 years ago
Created attachment 507485 [details] [diff] [review]
Tests

Updated tests to make sure the test actually finish on trunk (currently 8 passes and 10 fails).
Attachment #482208 - Attachment is obsolete: true
Attachment #482208 - Flags: review?(jst)
(Assignee)

Comment 10

6 years ago
(In reply to comment #8)
> I'm keeping this as a blocker because I believe in test driven development
> yatta yatta, but tests don't need permission for approval so I question whether
> or not this even needs soft blocking status.

FWIW, the real purpose of the bug is to make trunk pass this test.
We're past feature freeze.  This sounds like a non-blocker to me.
blocking2.0: betaN+ → ?
Whiteboard: [softblocker]
Yeah, we should get these tests in in a form where they pass, but we did change our minds on what the exact security policy is wrt document.domain. Either way, this is not a blocker any more due to the policy change.
blocking2.0: ? → -
status2.0: --- → wanted

Updated

6 years ago
Blocks: 655649
Depends on: 729150
Created attachment 637462 [details] [diff] [review]
Better tests. v1

I spent some time with the tests on the bug this morning and found them inscrutable and impossible to extend. Here are some much cleaner ones.
Attachment #507485 - Attachment is obsolete: true
Attachment #637462 - Flags: review?(mrbkap)
Note that we're now explicitly testing for the behavior I proposed here: http://lists.w3.org/Archives/Public/public-script-coord/2012AprJun/0120.html
Comment on attachment 637462 [details] [diff] [review]
Better tests. v1

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

::: js/xpconnect/tests/chrome/test_documentdomain.xul
@@ +32,5 @@
> +  function startTest() {
> +
> +    // Grab all the content windows. We waive Xray here, and add it back with
> +    // XPCNativeWrapper whenever we pass references into content.
> +    var win1A = document.getElementById('test1A').contentWindow.wrappedJSObject;

All of this futzing around with .wrappedJSObject and XPCNativeWrapper shouldn't matter for the case where we're passing object around... I think you should be able to nuke it.
Attachment #637462 - Flags: review?(mrbkap) → review+
Pushed to m-i:
http://hg.mozilla.org/integration/mozilla-inbound/rev/c9b038fa6956
https://hg.mozilla.org/mozilla-central/rev/c9b038fa6956
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla16
You need to log in before you can comment on or make changes to this bug.