Re: Fwd: A question about multithreading in gecko using javascript
David Rajchenbach-Teller wrote: On 12/20/12 7:27 AM, Ray You wrote: How can we start a real thread in gecko using javascript and use XPCOM in it? Is dispatching events to /nsIStreamTransportService/ or /nsIThreadManager.newThread(0) /the right way? I don't think this is supported anymore. As far as I can tell, if you truly need to call XPCOM from JS in a background thread, you need to do the following: - write extern C code that calls into XPCOM; - launch a Chrome Worker from JS; - link JS to your C shared lib through js-ctypes; - call your C code from JS through js-ctypes. IIRC XPCOM exposes a C-compatible API, but I don't want to be the person who writes a wrapper for NS_InvokeByIndex ;-) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tablet vs. Touch: decision
On 19/12/12 10:21, Gervase Markham wrote: On 18/12/12 18:51, Alex Keybl wrote: Agreed that major fallout is unlikely - do we have a list of the most heavily used mobile tablet sites to verify that this change will not cause severe web regressions though? I will consult the wonderful Mr. Mandel. It appears that no-one has tablet-specific data. We will have to make do with mobile-specific data. :-| When do you expect to have a final comms plan (blog posts and necessary TE)? Thanks! It might be in the New Year now, but hopefully sooner. Please critique this: 0) We make sure that everyone who needs to know about the change knows that it's in the pipeline, even if we can't give a final ship date. That's the product owner of Fennec, the Toolkit module owner, and Fennec release-drivers. 1) We make a patch and check it in to Nightly, and uplift to Aurora. Rationale: attempt to reduce the number of browser versions out there with this change. Rather than 6 weeks on Nightly and 6 on Aurora, better to skip straight to Aurora for wider coverage and stay there longer if necessary. 2) We ask the Mobile testing team to be on particular lookout for site regressions in Aurora, and use Phony to try and test whether it's a UA issue. 3) Every time a significant problem is reported, the change is put on hold and does not advance until we deal with it. 4) Once the change moves to Beta, we set off the sirens again, making blog posts, warning product owners, release drivers etc. and make sure everyone is still OK with it. That gives 6 weeks of warning. If this doesn't work, please supply improvements :-) Gerv ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Filing bugs for intermittent failures on TBPL - new keyword
Hi all Bugs filed for intermittent failures (aka random oranges) seen on our test automation have now been transitioned to using a new bugzilla keyword instead of the whiteboard annotation. This helps to reduce the load on bugzilla caused by TBPL's BzAPI calls, when it searches for bugs to suggest for failures. ** As such, if filing a bug for an intermittent failure on TBPL, please remember to add the keyword intermittent-failure, otherwise TBPL will not suggest it. ** The whiteboard annotation [orange] and meta bug dependency should no longer be set. If you have any questions about the best way to file an intermittent failure (or are not sure if it is new), I'm more than happy to assist on IRC (:edmorley #developers / #ateam) or drop me an email. (For plans to add a bug filing mechanism to TBPL, see bug 779529. This will likely be implemented as part of TBPLv2). Best wishes, Ed ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Fwd: A question about multithreading in gecko using javascript
1. Can we call XPCOM in js-ctype code? 2. What about this code in DeviceStorage implementation? https://mxr.mozilla.org/mozilla-central/source/dom/devicestorage/nsDeviceStorage.cpp#1121 nsCOMPtrnsIEventTarget http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=nsIEventTargettarget http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=target =do_GetService http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=do_GetService(NS_STREAMTRANSPORTSERVICE_CONTRACTID http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=NS_STREAMTRANSPORTSERVICE_CONTRACTID); NS_ASSERTION http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=NS_ASSERTION(target,Must have stream transport service); nsCOMPtrInitCursorEvent http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=InitCursorEventevent http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=event =new InitCursorEvent http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=InitCursorEvent(this,mFile http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=mFile); target http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=target-Dispatch( http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=event http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=event,NS_DISPATCH_NORMAL http://dxr.mozilla.org/search.cgi?tree=mozilla-centralstring=NS_DISPATCH_NORMAL); I notice that there are assertions on both /NS_IsMainThread()/ and /!NS_IsMainThread()/. Seems like it really starts a backstage thread in DeviceStorage implementation. Is this true?/ / -- Best regards, ??(Ray You) On 12/20/12 7:35 PM, David Rajchenbach-Teller wrote: On 12/20/12 7:27 AM, Ray You wrote: How can we start a real thread in gecko using javascript and use XPCOM in it? Is dispatching events to /nsIStreamTransportService/ or /nsIThreadManager.newThread(0) /the right way? I don't think this is supported anymore. As far as I can tell, if you truly need to call XPCOM from JS in a background thread, you need to do the following: - write extern C code that calls into XPCOM; - launch a Chrome Worker from JS; - link JS to your C shared lib through js-ctypes; - call your C code from JS through js-ctypes. Cheers, David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing writable [Replaceable] properties
Gecko (not specs) has a concept of writable [Replaceable] attributes. It uses them for these properties: window.innerWidth window.innerHeight window.outerWidth window.outerHeight window.screenX window.screenY window.opener window.status window.name In our implementation, a writable [Replaceable] property lives on the [[Prototype]] and has getter/setter-ish semantics associated with it, although (bug) you can't use Object.getOwnPropertyDescriptor to tell, as they use the old bindings code. Getting such a property gets a value. Setting it creates a shadowing property on window itself, using the exact value passed in. // Current Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // string, not number I'm making some changes near the code that implements this. These are very desirable changes, but they make it complicated to preserve these bizarre semantics. The easiest change is to get rid of writable [Replaceable] entirely, and make all these accessor-y properties: getting them gets whatever, setting them invokes the setter, getting them again gets whatever value the setter coerced it to. // Proposed Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // number (setter coerces string-number, or the setter silently did nothing) This is compatible with IE9 (standards or quirks mode -- and not in IE9 compat mode, and it seems not in older IE modes; I don't have IE10 to test) and Opera behaviors. IE9 puts the accessor on Window.prototype, and Opera puts it on window, but there's no visible difference in behavior for getting or setting. But there's still a supposed compatibility bugaboo to changing, because sites might have relied on the old behavior (notwithstanding that browsers are all over the map here), and other browsers aren't quite the same. WebKit gives the old behavior, but only for some of the listed properties -- it doesn't for status or name. (And it provides writable-[Replaceable] behavior for other properties beyond these: window.locationbar/menubar/personalbar/scrollbars/statusbar/toolbar/navigator/clientInformation/screenLeft/screenTop/scrollX/scrollY/devicePixelRatio/console/performance definitely. It might also for window.event/length/self/window/frames/opener/parent/top, but there's some extra complexity to these, so I'm unsure how they look.) Anyway. I think the compatibility bugaboo is just that -- we have no hard evidence of dependence on our current bizarre semantics, and we have other-implementation evidence that the proposed behavior is web-shippable. Thus I think we clearly should switch as proposed, aligning us with IE going forward and with Opera, and with the specs as well. Thoughts? Jeff P.S. -- The SunSpider test that used an undeclared name variable no longer does in SunSpider 1.0, so concerns about window.name particularly are unfounded. (Not to mention SunSpider is increasingly obsolete as a benchmark, and all the JS engines are doing their best to kill/ignore it.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
On 12/20/12 12:14 PM, Jeff Walden wrote: Setting it creates a shadowing property on window itself, using the exact value passed in. // Current Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // string, not number Er... no. If you do that, you get number for the second alert, because you did a qualified set. That's the whole complication with these properties: they behave differently for qualified and unqualified sets. // Proposed Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // number (setter coerces string-number, or the setter silently did nothing) This is compatible with IE9 (standards or quirks mode -- and not in IE9 compat mode, and it seems not in older IE modes; I don't have IE10 to test) and Opera behaviors. IE9 puts the accessor on Window.prototype, and Opera puts it on window, but there's no visible difference in behavior for getting or setting. But there's still a supposed compatibility bugaboo to changing, because sites might have relied on the old behavior (notwithstanding that browsers are all over the map here) So specifically, for unqualified sets right now Gecko and WebKit reconfigure the property to a data property, as do older IE, but not newer IE or Opera, right? And the proposal here is to align with new IE and Opera? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
Seems like a reasonable change to me, for the inner*, outer* and screen* properties. I don't know about the others. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
On 12/20/2012 03:38 PM, Boris Zbarsky wrote: On 12/20/12 12:14 PM, Jeff Walden wrote: Setting it creates a shadowing property on window itself, using the exact value passed in. // Current Gecko alert(typeof window.screenX); // number window.screenX = 123; alert(typeof window.screenX); // string, not number Er... no. If you do that, you get number for the second alert, because you did a qualified set. That's the whole complication with these properties: they behave differently for qualified and unqualified sets. Oops, sorry, you're right. I suppose I should mention for clarity that what I'm doing is trying to remove this difference. There is no spec way to distinguish between a qualified and an unqualified access to a variable, to get or set it. The [[GetP]] and [[SetP]] hooks that are part of ES6 (which is slightly reformulating this), and the [[GetOwnProperty]] and [[DefineOwnProperty]] hooks that are part of ES5, do not allow passing along qualification. In the case of getting a property, all you get is the object, and the property name being looked up. In the case of setting, you also get the value that goes along. And if you're defining, you get a descriptor with a value and some set of property attributes. The other operations, like [[HasProperty]] and [[HasOwnProperty]], also all take just the object and a property name/key. And the proposal here is to align with new IE and Opera? Yes. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
