Platform/JS Compartments Mochitest: Difference between revisions

← Older edit

Platform/JS Compartments Mochitest (view source)

Revision as of 02:10, 14 October 2010

2,928 bytes removed , 14 October 2010

→‎Mochitest

Jst

Confirmed users

839

edits

@@ Line 48: / Line 48: @@
 = Mochitest =
-Run with <code>python runtests.py --total-chunks=20 --this-chunk=n --autorun --debugger=gdb</code> where <code>n</code> is the chunk you want to examine.
+Pass.
 == Remaining large-ish items ==
@@ Line 75: / Line 75: @@
 <pre>
-http://mochi.test:8888/tests/dom/tests/mochitest/whatwg/test_postMessage_joined.html
 </pre>
@@ Line 81: / Line 80: @@
 <pre>
-http://mochi.test:8888/tests/toolkit/components/microformats/tests/test_Microformats_add.html
 </pre>
 = Mochichrome =
-failing tests out of 14051, in these files:
+<pre>
+</pre>
- chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_evalInSandbox.xul
- -> add a function that the sandbox can call which forwards to getClassName
-No idea what that comment about getClassName means.  What is happening here is that the test is using exactly the same technique GreaseMonkey uses to set up the sandbox, and that doesn't work anymore.
-The specific issue is with code that does <code>sandbox.__proto__ = new XPCNativeWrapper(window);</code> where the caller is chrome, but ''sandbox'' and ''window'' are same-domain. When we rewrap the XPCNativeWrapper, it becomes a simple cross-compartment wrapper without X-ray behavior.
-The whole rewrapping mechanism works as designed right up to WrapperFactory::Rewrap where it's actually time to create the new wrapper. We have a ''flags'' parameter that indicates we want X-ray behavior. But we create a wrapper without it.
-We could just make that work, but mrbkap thinks we should instead provide a better sandboxing API and require GreaseMonkey (and any similar extensions) to switch to that.
--jorendorff, 10/5/2010
   chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul
@@ Line 123: / Line 109: @@
 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | iwin.eval does not throw an exception
-iwin.eval("'PASS'") must not throw an exception. But it is throwing.
+iwin.eval("'PASS'") is supposed to succeed, but iwin.eval is undefined.
-iwin.eval is undefined.
 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | Unable to wrap a primitive, even without 'new'
@@ Line 133: / Line 117: @@
 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | XPCNativeWrappers allow expandos through
+ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | delete doesn't delete underlying properties - got undefined, expected 5
      let iwin = $('ifr').contentWindow;
      let (w = new XPCNativeWrapper($('ifr').contentWindow)) {
          w.foopybar = 5;
          ok(!("foopybar" in iwin), "XPCNativeWrappers allow expandos through");
-        ...
-XPCNativeWrappers must not allow expandos through. But they do.
-ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | delete doesn't delete underlying properties - got undefined, expected 5
-    let iwin = $('ifr').contentWindow;
-    let (w = new XPCNativeWrapper($('ifr').contentWindow)) {
          ...
          iwin.foopy = 5;
@@ Line 149: / Line 127: @@
          is(iwin.foopy, 5, "delete doesn't delete underlying properties");
-Again, an XPCNativeWrapper must not allow chrome to delete expando
+We create an explicit XPCNativeWrapper ''w'' around ''iwin'', a wrapper of an outer window. Expandos of ''w'' must not affect ''iwin'' and vice versa.
-properties. I'm not sure why we don't want to allow that, but we're allowing
-it.
+I think the basic story here is "there are no same-compartment X-ray wrappers".
 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/js/src/xpconnect/tests/chrome/test_wrappers-2.xul | allowed to update iwin.__proto__ to null - got [], expected null
@@ Line 163: / Line 141: @@
 -jorendorff, 10/5/2010
-I am also getting these failures:
-ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/layout/base/test/chrome/test_printpreview.xul | Timers should have run! - didn't expect "0 timers", but got it
-ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/layout/base/test/chrome/test_printpreview.xul | Timers should have run! - didn't expect 0, but got it
 = Browserchrome =
-Failures:
+Pass.
-<pre>
-chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_webconsole_netlogging.js
-chrome://mochikit/content/browser/browser/components/sessionstore/test/browser/browser_461743.js
-chrome://mochikit/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowser_newwindow_stopcmd.js
-chrome://mochikit/content/browser/browser/components/privatebrowsing/test/browser/browser_privatebrowsing_forgetthissite.js
-chrome://mochikit/content/browser/browser/components/preferences/tests/browser/browser_privacypane_1.js
-chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_sidebarpanels_click.js
-chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_library_middleclick.js
-</pre>
 = make check =
-Passes
+Pass.
 = make jstestbrowser (jsreftest) =
-We're seeing this consistently on debug builds on try.
+Pass.
-<pre>
-TEST-UNEXPECTED-FAIL | js1_8/regress/regress-464418.js | application timed out after 330 seconds with no output
-</pre>