Re: Overview of what you can do with Telemetry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/10/2015 11:25 PM, Vladan Djeric wrote: > Intern presentation schedule: > https://mana.mozilla.org/wiki/display/globalstaffing/2015+Intern+Prese ntations Nothing > public? Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVyaLMAAoJEOXgvIL+s8n224EIAIRv+L9tEHK4402eEXICymBn +5IhVPjXraokU/tLeeCZWf41OJIQPdP5/UD9IixkwFiwxQl6dUDNZoFcZEetuNPH ZHUTMTckxpaN5GkZ+6H6XRSHxIqVpqpQWXI3tClPjnFCZ/aaTtdZ1y/cWjqpHCfr VQlqQTlCFljzTyzCJXLkBiQe/4LbwDIRv/yf2DLGLsNomJ+j7k9ixoybSb0wBuQo HHAMpL3kTyC/0zC/OOnITEywl5zMaUrcgzn7AjQl+7i0DkhLGDOg62fG6mZ9ppmX giYIkmqSKDKzU/Uv4KiMX6ucJ2qsLcLAB6M0YR2gpsT1UCxRlsPj0KPKMgeQGpw= =Kh9P -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/26/2015 03:36 PM, Ehsan Akhgari wrote: > Hmm, I see. Have you considered the implications of making the > alias falsey in conditions, similar to document.all? No. No. Nononononono. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJV3dq3AAoJEOXgvIL+s8n2LvwIAIgP8Sw0LUU7ietAmwMPzQGU QykxqEWJr7Y/O+rSU2FmmXzeZWzBRtlh67F5V6yGPPgdljXEtq2pbQjhN3GCM1M/ k7ix7exbJVypy5Xi3NlXIxTaT0leCBImKhZGvkkRfiNap8meWglbFqEY228rNa8M hw9o5tRvjuhX4INU06ihlvqt/sCJqhyyy5o/ggM2xbuTO0IvksTK4SlGuaK9rxAX uQDIh+ss7Xv0Cex1izPOOeQkJnyPQtUB7wzf5WSHVXoSh63SDx7MhQ0BFKTOaVVp PYmW5pndDi4657lzmbzTaW1t418RmvQZ5/RfmKbJJyVAKqnQQ6+/4fGdxE814/M= =+/Wn -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: Web Platform and Timed Media Working Groups
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/10/2015 06:36 PM, Jonas Sicking wrote: > If I am the only one that wants to put in a formal objection here, > then I'll let it go and go with whatever everyone else think we > should do. > FWIW, I agree with Jonas that this is a terrible idea. (Even if we're the only Member raising a formal objection, I suspect Mike(TM) Smith would be happy to amplify the message internally.) OTOH, maybe we should just move the remaining useful specs in WebApps to WHATWG; that'd solve the issue once and for all. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJV8dZYAAoJEOXgvIL+s8n20z0H/0Wt4sj+zvpbS/GAPdY/S+wM sF666a9pTZ9N6bdMu9o+vcVM9s1GvP3mra1DwZHe9kfCAklfrjIWrgZ0gjMmvB6e q6reK1l4cbVGyoqCm9b32IqokHCe7wdT7Mm7m8HoSg3SdNCrWyHxfYDIshkO15aw 1xTHwamLDXmlDt94KU36EUdJAmu0j0pN8mvxiVG4FELWHAToGnlJ9l2ionoviqGl /NoQeEASW0TXt1C7Prq7XArLm7mX669z/FPrMhFgHpwyGoxP11BQy0zpCcZzSdlH dsh9yNyS4iabtHjbZVAbCbUxiNGC0ZhDoOmI3l1aYLO0uWPy4iyJRecW8iJonBU= =DO5p -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: Canvas CaptureStream
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Andreas, On 09/18/2015 04:39 AM, Andreas Pehrson wrote: > Other UAs intending to ship it are at least Chromium/Blink, who > have started work in this bug: > https://code.google.com/p/chromium/issues/detail?id=524218. > That bug does not seem to support the claim that they intend to ship this feature. No intent-to-ship is mentioned, and it appears the intent-to-implement has not been sent. Have other browser vendors provided any implementation feedback? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJV+9MXAAoJEOXgvIL+s8n2g+oH/2Hjp/oW5yiAPcZeBbelkG7Q ocK3q6hHDMKNF9Tubyvv33ciEjDkvgoUXQEMuvrnz09EPuR4el0L4GsRk65iJwR6 eWay0ndxBjbNJ/0v7GFHPmr66tK9eauIKe467kOW5YUWlopPuuVfOsv54IoIJ0ln SeuxXESOyKLFwqV78dAwHgwFPNRzMO2C18fOkfC+rVeWYytKlqkOnf2gbwd9chsY ncdS5k8ZkecOq5T8vJ+sCDRUnwOFEy/QPgoDC7vt66kuu0naj7fwr2kxr3Ic0yM6 rxXUdCZkscdAICLNgQfnHAm0PuKQRx8X9MzzudTL8ZKMXYDbq+F9SGX8L6hDrEM= =OqsW -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: HTMLElement.innerText
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2015 06:02 AM, Robert O'Callahan wrote: > https://bugzilla.mozilla.org/show_bug.cgi?id=264412 > > Webkit, Blink and Trident have been shipping this for years without > a spec and with poor interop. We held off on implementing it since > you can polyfill a better implementation in JS without much > difficulty, but we have to implement something for Web compat. > Because Mozilla, I've drafted a spec here: > https://github.com/rocallahan/innerText-spec which will hopefully > find its way through the W3C WICG, but given the state of the > world, us shipping this with or without a spec can hardly cause any > more harm. Please submit tests to web-platform-tests and create a pull request to the HTML standard. Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWJN+pAAoJEOXgvIL+s8n2z6oH/jhSjQw3ZLxFlFTtFqwcjQzL 3sS8HdLQbZ4t5lueZAujE80HLWaWBS5nEVXkP5F25Va/u6Y6LmeLSqHx/6VnmuY7 kRpXFylJ8WsXEi0H3GBwGBaVjjgc+7y+SJCq9YcBzyGzKiIcvSMdRNSaXt051BSM vpRTEL5j+wiUTHXSNsOHDVF7xG+rFwHqElQvkWyvye/ENnY45N9iuK3ctozAku3s PlETA8VGcjQQu3Y1nuejBxrvdQ9uPjb2xO0ZI998MwqIdn4i/BUhfS46zBJzjnwI 469Qyc+h9+PH953X4Ce1jjgRh3eh0YOrwtAyYxcVXIXPAmXeOoaDe/iasPV05O8= =XBnK -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendations: Canvas 2D Context & W3C DOM4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 10/21/2015 12:13 AM, L. David Baron wrote: > Two W3C Proposed Recommendations are available for the membership > of W3C (including Mozilla) to vote on, before they proceed to the > final stage of being W3C Recomendation: > > HTML Canvas 2D Context http://www.w3.org/TR/2dcontext/ deadline: > October 21, 2015 (tomorrow!) > > W3C DOM4 http://www.w3.org/TR/dom/ deadline: November 3, 2015 > > Both specifications are derived from upstream WHATWG > specifications. > > If there are comments you think Mozilla should send as part of the > review, or if you think Mozilla should voice support or opposition > to the specification, please say so in this thread. (I'd note, > however, that there have been many previous opportunities to make > comments, so it's somewhat bad form to bring up fundamental issues > for the first time at this stage.) > > (Sorry, should have sent these out a bit sooner.) Does this mean that the W3C is claiming that the features in these forks have interoperable implementations, and should we point out what utter nonsense such a claim would be? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWJ4O4AAoJEOXgvIL+s8n25y8IAJrdgXFgQOeabi8p9Lix2guQ DuUZT78TaPtRvF1cBbMpcWqzHgcUxYVGyntJWC+4UzJZ0uew8s5ONM3kIKO/VyNh KMKDRtTMxxRn00Y8LOPaLf3UW+Fcv+4Y1beifmlYougJYd0kagSqmNpJEnXcCz97 QUIgl1+8uRyoJwiNxPg0nQJB+oHQ0LPe9kZYFQHEwC1wyyWgDTUZORAJMaRtNXOr CstZ1wcMzmas098g3tSRJgX9bkee+PKXoVxm9t/nNDTlcCDTd+W157xAdFS4uqQW h8rLO7OFAF/wMJtNJ8uuA3W70BiBWOqG5cw2VfxQiKNqmZ0YRBJeQfgISuEkX+I= =iaAo -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Merging comm-central into mozilla-central
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/23/2015 09:57 AM, Mike Hommey wrote: > - It adds burden to developers, needing to support those projects > merged from comm-central. Just look around in mozilla-central at > all the optional things that are not visible on treeherder and > break regularly. The situation wouldn't be different in that sense. > But the people that do care about those projects will have a better > experience supporting them. I don't believe this would really add a burden; we haven't had thunderbird bustage block landing code in the past, and we're not about to start. One other argument against the merge I can see is machine load: right now we don't run c-c automation in response to changes on our integration branches, but only on the merges to m-c. Perhaps we should keep doing that for now. On the plus side, it could make it easier to share code between thunderbird and the b2g email code. > Considering all the above, are there still objections to this > happening, and can we finally allow Joshua to go ahead with his > merge plan? (CCing bsmedberg, who, iirc, had Brendan's delegation > to have the final word on this) Strongly in favour for all the reasons you mentioned. Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWKftoAAoJEOXgvIL+s8n2ALEH/3quXXrs7lAn1qiWjdj0nfTE r6qbmHHUL1OlfkipeFLy+vjLmI2g5ep/aKlAfYBILowaQgzFlXUiTBiz1+Yz2ChD 1UzCHOGKxcPLNYVpgEu5snBjdWhPk1DJZk5DMt390V2ldU4LVfF0f9FvIsXW6n2G Cov/GS3KPk3rJToi82ZTjpFJdRMdh/WP6ePxDvRRJsgYiRUtdBu0jhA2Pqi0B1x6 /gmK/i0Jaw5UP/1QZd5JUjuWTuDc2Ta8bX/a3AJ/TSXbXYVcVOMrv7U55sRbN6aA qbqNAZ/0LsCNRLqA7+2uzUV4+riX9ISgiruuL8wQJCtTXRT4KuZlmqCzDRJ3Ots= =8jpM -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship/unprefix: Canvas2D imageSmoothingEnabled
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/29/2015 04:34 PM, Florian Scholz wrote: > Hi, > > we intend to ship ctx.imageSmoothingEnabled and add a deprecation > warning for ctx.mozImageSmoothingEnabled. > > This is a Canvas2D context property which controls the > interpolation of images drawn to 2D canvas. > > Bug https://bugzilla.mozilla.org/show_bug.cgi?id=768072 > > Spec > https://html.spec.whatwg.org/multipage/scripting.html#image-smoothing > > MDN > https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContex t2D/imageSmoothingEnabled > > > > Blink and WebKit unprefixed awhile ago, too: > https://code.google.com/p/chromium/issues/detail?id=277199 > https://bugs.webkit.org/show_bug.cgi?id=147803 Do we have a test suite that shows our implementation is interoperable with Blink's and WebKit's? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWXBESAAoJEOXgvIL+s8n2NcEH/0YsqESTN+lOYckFADa27c1D JyL3pTFuAoLDqiIO9WXZVMe15rCZp9r5HJsDmqhYPNkIk5Mnn9eZXjPsEo8Pi+uD aSwip1Cf5U0pn7DDeAUYOsEj8JVkwbrJhb2DUzmq0PNUUcHYEBG0hlmf8W6obdvU BhWAKCV7OwK1JF+Zw6qEjFtams25syo3VmB3rgclzBqi0DZ7CRMCUnzbJgcwnkSN QstbKcTGT/E62bEqW+Xxj0Zva3CEqWbTiub9V/iGimN4aq2vQRjuo/PzsNqcx+cN sG01RqqZSmCDC1lW+W0HGz2vFpOfredEdKgc00fxzhJ1TJFm077OUgULTrAFD/w= =HVw2 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: referrerpolicy attribute
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2015 10:58 AM, Franziskus Kiefer wrote: > As of Firefox 45 we intend to turn referrerpolicy attribute on by > default on all platforms. It has been developed behind the > network.http.enablePerElementReferrer preference. Other UAs > shipping this or intending to ship it are Chrome and Opera [1]. > > The referrerpolicy attribute as specified in the referrer policy > spec allows per element referrer policies for , , , > and tags. Referrer policies allow to specify which referer > [sic] header is sent when performing the request. The > referrerpolicy attribute allows developers to override the > document's referrer policy (set in meta tag or via CSP) on a per > element basis. > > This feature was previously discussed in this "intent to implement" > thread: > https://groups.google.com/d/topic/mozilla.dev.platform/g-YY5rWFCLM/dis cussion. > > > > *Bug to turn on by default*: > https://bugzilla.mozilla.org/show_bug.cgi?id=1223838 *Link to > standard*: https://w3c.github.io/webappsec-referrer-policy/ [1] > https://www.chromestatus.com/feature/5743723954569216 > Do we have tests in web-platform-tests that show our implementation is interoperable with Blink? I believe there was a capitalization issue with this feature; has it been solved and the solution implemented everywhere? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWXsPnAAoJEOXgvIL+s8n2FIkH/2jkW3tYftCwNnTNScSCBvrq UQTsPruJJPzTQL1lVfMV3Nl+JoieFLvpgPlZc2HG4AY0m5c95A+lAwHAbt6bu/GY nYmctz+e0Mktau2IGvTon6G4QO5kRy/boXX4N2m7E/cAzkC7H8dfFC5AD5jtsqo7 F8FqmQah1RrcvtUrrqvfGi5Va5bLdKVD2WEkbR7vlWr7ubSzNsCtJSe2P6oKOeet Ys9f6n+RLOoWLI9CUqNBt2WqLSxJDf+gIgXEm3p+3D718BZg+zLe2d6u5SV3NuEw zljxSHADse/zobwgCPvXLL6hpaDVFBLC45TccGRIVIPBcyeT0tHngGO/EYZpejI= =rHo4 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: FIDO U2F API
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2015 03:48 PM, Richard Barnes wrote: > I think we would treat this just like we treat other early-stage > things that get shipped, gradually turning it off when the real > thing shows up. That would mean only shipping it on Nightly and maybe Aurora for now. > I don't remember what the current conventional wisdom about > prefixing is, but I would be open to shipping with a prefix if > people thought that would ease pain in the eventual transition. No. Nonononononononono. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWXwXcAAoJEOXgvIL+s8n2ZwIH/2XJbkWFfG57Bvsum1EIREVz bSbRXE3eLsUyYtOIWhT8NX3PWuvqFH8/xmkvTGq57CwHxVQiHT6Su+voLG7qLNpK pInNX475lLK/oj81mHvRAlymlC3MjVHWp53UeAz1fTW3i66ez0YT/vZtD2iA5YMo iOcIL6VhSXFUHI8yWwFJIcQ/p60pwRBOEA9IJIIAJJk84xf9tEakNbqM1pQwFesW ROyL7ZFOxLH/oGWCPWxoYfM/btfEqcYDC4FuEsd4SIruyD8liGJ3SMLnXkt7y9k8 8RcfqfUKjlhbE2fzzOf0ooNokpmzhxk2flEzNX8Y/bWl8glMKsbs0Dy89re8tTw= =Z0LB -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2015 04:54 PM, Henri Sivonen wrote: > On Fri, Dec 4, 2015 at 3:18 PM, Ted Mielczarek > wrote: >> 1) What does Servo do, just use rust-encoding directly? > > That is my understanding, but it would be good if a Servo > developer could confirm. This is correct. >> 2) Instead of a clean-room implementation, would it be possible >> to fix the problems you see with rust-encoding so that it's >> suitable for our use? Especially if Servo is already using it, it >> would be a shame to wind up with two separate implementations. > > I'm shy to suggest to the rust-encoding maintainer that I should > be able to come in and trample all over the rust-encoding > internals because of Gecko and what I see as priorities from the > Gecko-informed point of view. It doesn't make sense to implement a > Gecko-ish API where the caller allocates the output buffer (like > I'm proposing) on top of rust-encoding. However, it would make > sense to implement (at least the common call patterns of) the > rust-encoding API on top of the kind of API that I'm proposing. But > in order to do so, the internals of rust-encoding would end up > replaced with the kind of library that I'm proposing. > > As for whether any parts of the rust-encoding internals would be > reusable in the kind of library that I'm proposing, as noted in > the proposal document, it generally makes no sense to adapt one > implementation strategy for the single-byte encodings to another. > If you want a different implementation strategy for the > single-byte encodings, it simpler to just rewrite from scratch to > the strategy that you want. > > As for the multi-byte converters, the concern I have is that > rust-encoding implements them using a macro that generates a state > machine and this makes the code look different from the algorithms > from the spec. It might be really dumb of me to suggest not using > that macro, but I think there is value to having the code look like > the algorithms in the spec so that it's easy to compare the two. So > in the case of multi-byte converters it's mainly a question of > whether we prefer the (possible really cool) macro or code that is > easy to compare with the spec. I currently prefer code looking like > the spec, but maybe I could be convinced otherwise. (Either way, > I'd get rid of the encode-optimized lookup tables and search the > decode tables in reverse instead.) > > It would probably be worthwhile to copy and paste from the > rust-encoding UTF-8 and UTF-16 converters. I agree that it is useful to have code looking like the spec in the general case. However, if we were to get to the point where that was the only argument against unifying your proposed library and rust-unicode, I think we should probably go for the unification anyway. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJWYblSAAoJEOXgvIL+s8n2uwQH/ipxhkqZpqZIEZIZcAezbKfw 1on3mC/0cnwJywu9yqqlTSXAoQJxONbdWeLJnRU9RvEgreT+EOp+0ktRgUubg34h qAew1zdRhS7ldIZTWyePX4EOpUsvtIqXXpyJcw3Tl76bTx+skp3mov+lhZxTLS/3 ZsDayhHuYwhSB/h2KfYP09ee5i3AyKPjWkPyWIMw9jRXxJD+bWVcj++V1s2/3V9R A4MnAJOB8Cqyhp+aMi1+mbx2QTYEqXqLak9ifKV0hHfF80+qI3aGkFQhr/fbhdgl 9rSBz7gI4lVzXtt8wSNaBGnRSf5mGvGmz5wQC7VyGtj2NMYKcmbCErXavhiSW6g= =ixRO -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement/Ship: -webkit-text-stroke
On 14/04/16 09:26, Jeremy Chen wrote: > *Summary*: We don't currently support -webkit-text-stroke; however, it has > been available for years in webkit based browsers and has seen widespread > usage on the web. This css property is currently available in Chrome and > Safari. How about Edge? Should we implement an unprefixed version as well? > Preference behind which this will be implemented: > layout.css.prefixes.webkit Should this have a more specific pref? Thanks Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Notes about implementing DOM APIs in Rust
On 22/06/16 19:05, Henri Sivonen wrote: > We shouldn't expect to be able to use Servo's implementations of DOM > APIs in a drop-in a manner in Gecko. Because Servo allocates Rust > objects on the JavaScript heap, but Gecko doesn't allocate C++ objects > on the JavaScript heap, For the record, this is not true. The significant difference is that Servo creates a reflector (JSObject) for any DOM object as soon as it is created, and this reflector is responsible for the deallocation of the DOM object. Gecko instead manages the DOM object through reference counting, and only creates a reflector when JS code needs it. > the memory management arrangements of the two > engines are fundamentally different and, therefore, the same WebIDL > bindings won't work. ... but your conclusion remains correct. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MXR permanently offline, please transition to DXR
On 22/06/16 20:30, Lawrence Mandel wrote: > Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was > taken offline on June 13, 2016, to investigate a potential security issue. > After careful review of the codebase, we have decided to accelerate the > planned transition from MXR to its more modern equivalent, DXR ( > https://dxr.mozilla.org), instead of bringing MXR back online. I wish the years of complaining about MXR had led to an equally useful replacement for it by now. Sad to see it go. Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: CSS Houdini - Properties & Values API Level 1
Hey Jonathan, On 22/07/16 23:26, Jonathan Chan wrote: > Summary: > > Allow web developers to register typed and animatable custom CSS properties > through JavaScript with configurable inheritance and initial values. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1273706 > Link to standard: https://drafts.css-houdini.org/css-properties-values-api/ > Platform coverage: all platforms > Estimated or target release: This will likely be available, preffed off, in > Firefox 51. Release date (for the pref-flip) unclear -- may depend on our > implementation timeline for other Houdini specs. > Preference behind which this will be implemented: > layout.css.properties_and_values.enabled > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1287171 Do we know how other vendors feel about this? Are there automated tests that will be shared with other vendors (and Servo)? Thanks Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to unship: WorkerGlobalScope.onclose
On 22/08/16 10:03, Andrea Marchesini wrote:
> I'm planning to remove |partial interface WorkerGlobalScope { attribute
> EventHandler onclose; }|.
> This EventHandler has been in our code base since ever but it's not part of
> the Workers spec and no other browses implement it.
>
> In order to be compliant the spec, it's time to get rid of this.
> Any objection?
>
... and we will stop dispatching the clone event.
This is https://bugzilla.mozilla.org/show_bug.cgi?id=790919
Really great to finally see it gone!
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charter: Web Platform Working Group
On 29/09/16 03:02, L. David Baron wrote: > The W3C is proposing a revised charter for: > > Web Platform Working Group (formerly Web Applications WG & HTML WG) > https://www.w3.org/2016/08/web-platform-charter-draft.html > https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0001.html > > Mozilla has the opportunity to send comments or objections through > this Friday, September 30. > > Please reply to this thread if you think there's something we should > say as part of this charter review, or if you think we should > support or oppose it. > > -David > Given that (as I expected) the merger of the HTML WG with its profoundly dysfunctional processes into the productive WebApps WG created a completely useless WG, more focused on adding W3C logos to existing standards than doing actual work, my proposal is to disband this WG and move any remaining useful work to the WHATWG. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: Selection::setBaseAndExtent()
Summary: Addition to the Selection API that is used by Google Docs (and will hopefully help us improve our performance to match Chrome's) Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1321623 Link to standard: https://w3c.github.io/selection-api/#dom-selection-setbaseandextent Platform coverage: all platforms Estimated or target release: Fx53 Preference behind which this will be implemented: none DevTools bug: no need AFAIK Do other browser engines implement this? Chrome and Edge do; IE doesn't (according to the bug). I have no other data. Tests: added as part of the implementation: <https://hg.mozilla.org/integration/mozilla-inbound/rev/ddfcb1823adc> Security & Privacy Concerns: none (Please direct any further questions to Mats, who implemented the API.) HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to vendor Servo in mozilla-central
On 04/01/17 00:35, Gregory Szorc wrote: > Over in bug 1322769, we're planning to vendor the contents of the Servo Git > repository into mozilla-central as part of Quantum efforts. > > The initial vendoring of the Servo repository is the first milestone of a > larger project that aims to "unify" workflows and automation across the two > projects, allowing both projects to have insights into the other's > automation and allowing development work spanning both projects to be > simpler. > > In this first milestone, we will vendor the history of the Servo Git > repository into mozilla-central. > > We only get one chance to vendor the history of Servo before it is forever > set in stone in the history of mozilla-central. So I'd prefer to get it > right so we don't have regrets about the approach 10 years from now. > Therefore, if you care about getting it right, your brain and eyeballs on > the proposal would be useful. > > The current plan is to rewrite Servo's history to: > > * Remove merge commits (only taking the p1 ancestry of the repo) > * Add something in commit message summary line to indicate commit comes > from Servo > * Add source repo and commit annotations to the commit message > * Reformat some GitHub-flavored markdown to something more sane for plain > text display > * Remove everything related to submodules > * Drop WPT files (there's ~135,000 of them!) > > We also tentatively plan to introduce the Servo history as a new root in > the mozilla-central repository so that bisect operations on Firefox/Gecko > don't land in the middle of thousands of Servo-only commits. (I concede > this is an ugly hack to work around limitations of the "bisect" command of > your preferred VCS.) > > Unless we prune more from history rewriting, this will add ~8,000 commits > to mozilla-central touching ~5,700 files. The on-wire clone size of the > repository will increase by ~36 MB. On-disk repo size will increase by ~50 > MB (not including inode overhead). > > Also, I anticipate the techniques and tools used to import Servo's history > and keep it "synchronized" have uses outside of Servo. Our current > mechanisms for keeping upstream/third party projects in sync with > mozilla-central are not well standardized. I'd really like the work to > support Servo to be used for other projects as well. This potentially > includes a future where certain directories in mozilla-central are > effectively developed on GitHub or are using other "non-standard" > workflows. If you think you may benefit from this future work, I'd > appreciate if you could look at the Servo vendoring effort and make sure > things like the annotations tracking the original source of the commit are > sufficient for uses outside of Servo. > > Again, it's bug 1322769 if you want to comment or follow along. > As I said before, this approach is, IMO, much too complicated; splitting the reusable parts of Servo into their own repositories, as we have done before, would be a much simpler solution. However, as it seems the decision has already been made quietly long ago, I don't see much point in continuing to fight it, as long as this frankenhistory does not affect the canonical Servo history in git. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reorganizing some test directories
On 04/10/2013 09:07 PM, jmaher wrote: There are a couple common directory structures used for storing tests in the tree: 1) /tests 2) /tests/ I have a series of patches which will move most of the directory structures from #1 to a format of #2. This means we would see: /tests/mochitest /tests/browser /tests/chrome I have noticed this happens naturally in the newer folders (i.e. browser/metro). A couple weeks ago I heard a concern this might bitrot some patches, while that might happen in the last couple weeks only a handful directories had tests which changed (added/deleted/editing) such that my patches experienced bitrot. Please comment here or in bug 852065 as I would like to land these patch this by this weekend. I do not understand the purpose of these change. They do not appear to have any benefits. Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Forcing alphabetical order in moz.build files
On 04/17/2013 07:15 AM, Robert O'Callahan wrote: I have a request ... can we require lists in moz.build files to be in alphabetical order, and actually enforce with some build-system check? I'm always annoyed by Makefiles where lists are sometimes unordered and it's hard to find items and know where to add items. Fully agree, with the exception that I'm not sure this is a safe transformation for *DIRS. -- Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Automatic tree clobbering is coming
On 04/17/2013 09:36 PM, Gregory Szorc wrote: On 4/17/13 11:52 AM, Ralph Giles wrote: On 13-04-17 10:20 AM, Gregory Szorc wrote: I agree the behavior is not expected if you're coming from a traditional configure + make background. However, I believe automatic clobbering is what the plurality of people want. Can the mach tool do the clobbering then? If you're correct in your belief that will encourage adoption. It /could/, sure. However, I consider auto clobbering a core build system feature (sheriffs were very vocal about wanting it). As such, it needs to be part of client.mk. (Please correct me if I am wrong.) This should say …about wanting it *on buildbot*. I have not heard sheriffs being very vocal about anything to do with local builds. (Which means that that particular request could have been solved with an opt-in rather than an opt-out flag.) -- Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Nightly *very* crashy on OSX
On 04/21/2013 08:15 PM, David Ascher wrote: Mine is crashing on startup. Can't even get to profile chooser dialog. That'll be bug 863646. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Standalone GTests
On 05/08/2013 08:06 PM, Benoit Girard wrote: I personally have a strong preference for keeping tests, particularly unit tests, running fast. My workflow is to develop new code by testing it via unit tests so longer turn around times slow down my development workflow. Sadly we don't have a good a way with dealing with slow but efficient tests and they end up making it difficult to test locally. But this isn't a reason to reject a useful test so feel free to check it in. Perhaps we should consider introducing a concept of smoke tests for developers to run locally where we can aim to maintain a good trade off between code coverage and turn around times. But that's orthogonal to your request. I think splitting GTest into a separate test job should be a prerequisite to not slow down the build job significantly which AIUI reduces test turn around times by delaying all test jobs from starting. Test jobs are kicked off before 'make check' starts. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Replacing Gecko's URL parser
On 07/01/2013 08:30 PM, Gavin Sharp wrote:
.sOn Mon, Jul 1, 2013 at 10:58 AM, Benjamin Smedberg
wrote:
Idempotent: Currently Gecko's parser and the URL Standard's parser are
not idempotent. E.g. http://@/mozilla.org/ becomes
http:///mozilla.org/ which when parsed becomes http://mozilla.org/
which is somewhat bad for security. My plan is to change the URL
Standard to fail parsing empty host names. I'll have to research if
there's other cases that are not idempotent.
I don't actually know what this means. Are you saying that
"http://@/mozilla.org/"; sometimes resolves to one URI and sometimes another?
function makeURI(str) ioSvc.newURI(str, null, null)
makeURI("http://@/mozilla.org/";).spec -> http:///mozilla.org/
makeURI("http:///mozilla.org/";).spec -> http://mozilla.org/
In other words,
makeURI(makeURI(str).spec).spec does not always return "str".
Actually, the issue is that makeURI(makeURI(str).spec).spec !=
makeURI(str).spec.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Code coverage take 2, and other code hygiene tools
On 06/25/2013 03:50 AM, Clint Talbert wrote: So, the key things I want to know: * Will you support code coverage? Would it be useful to your work to have a regularly scheduled code coverage build & test run? I have looked at decoder's older code coverage data [1] before, and found it very useful. I strongly support getting it run automatically. One feature that would it make even more useful to me is code coverage for generated code, and the WebIDL bindings in particular. (When I last talked to decoder about this, it only covered files in the source tree; I don't know if that has changed since.) * Would you want to additionally consider using something like JS-Lint for our codebase? I don't want to derail this thread, but AIUI, JSLint enforces Douglas Crockford's style, which is not necessarily something anyone else wants to use. HTH Ms2ger [1] http://people.mozilla.org/~choller/firefox/coverage/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Stop #including jsapi.h everywhere!
On 08/20/2013 02:15 AM, Nicholas Nethercote wrote: They can be replaced by forward declarations of a handful of types, e.g.: struct jsid; This is not actually the case: jsid is a typedef for ptrdiff_t in release builds, so you'll still need to include jspubtd.h for it. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Silencing debug spew
On 10/01/2013 12:25 AM, Karl Tomlinson wrote: Bill McCloskey writes: # Silence ++THIS and --THAT export MOZ_QUIET=1 # Silence NS_WARNING export MOZ_IGNORE_WARNINGS=1 then you won't get any more messages about DOM windows or docshell creation/destruction or about NS_WARNINGs firing. Thanks very much, Bill. I think I'll also find this useful. Can we all agree to only use NS_WARNING for things that are unlikely to happen? This includes NS_ENSURE_SUCCESS and friends. I thought there was almost consensus on avoiding NS_ENSURE_* because of the way jump statements are hidden, but I've still seen some advocating. No. The NS_ENSURE_* macros are incredibly useful when trying to figure out where things went wrong. To witness, just yesterday, in #content: > * khuey points out that NS_ENSURE_ spew is awsome cause > otherwise he'd have no clue where to start http://logbot.glob.com.au/?c=mozilla%23content&s=30+Sep+2013&e=30+Sep+2013#c137495 HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 11/14/2013 11:49 PM, Ehsan Akhgari wrote: I've started to work on a project in my spare time to switch us to use unified builds for C/C++ compilation. The way that unified builds work is by using the UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that, the build system creates files such as: // Unified_cpp_path_0.cpp #include "Source1.cpp" #include "Source2.cpp" // ... And compiles them instead of the individual source files. One issue I only thought of today: this means that Source2.cpp can use all headers included into Source1.cpp–until enough files are added between Source1 and Source2 that Source2 ends up in the next unified file. This hasn't been much of an issue for autogenerated C++, but it seems like it could be harder to get right with hand-written C++. One way around it would be not to unify sources in automation. On one hand, this could cause more bustage when changes that built locally turn out not to have enough includes; on the other, it might be better than having to fix up a dozen unrelated files whenever you add a new one. Thoughts? Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Central location for tracking known broken build configurations (with bugs)
On 11/20/2013 08:11 AM, Tim Abraldes wrote: Somebody stop me if this already exists... I'm envisioning a central location, probably a wiki page at https://wiki.mozilla.org/BrokenBuilds or similar, where people can find the answers to these questions: 1. Given my current build configuration, why did my last build fail? 2. What bugs can I follow to see when this build configuration will work again? 3. What workarounds/patches can I employ to quickly get a working build? Sometimes the "topic" field in #developers contains a link to an etherpad describing common kinds of breakage. Not at the moment, though. That's handy! If we go with the approach suggested by gps, we could move the info from the etherpad (does anyone have a link to this etherpad?) into the doc as a starting point. In the future we could have the "topic" of #developers explain how to find the doc. The etherpad was at <https://etherpad.mozilla.org/commonissues>. Since it's been out of the topic since last March, though, I don't think anything there is particularly common still. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there any reason not to shut down bonsai?
On 11/21/2013 08:43 PM, Laura Thomson wrote: I'll keep it short and to the point. Are there any objections to shutting down http://bonsai.mozilla.org/cvsqueryform.cgi ? If you don't know what that is--and few people do, which is even more reason to shut it off--it's a search engine for some of our CVS repositories, of which I think none are in active development. It's the source of truth for pre-mercurial Gecko history; I find myself having to use it surprisingly often. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On closing old bugs
On 12/04/2013 09:30 PM, Lawrence Mandel wrote: I think David, Nick, Henri, and you are right - there are lots of old bugs that we each think are important enough to fix. (Yes, I have some as well.) In my mind the real question is, given all of the work that we all have to do, are we going to spend the time to fix these bugs? If not, as a reporter would you prefer to see your bug go untouched for an indeterminate amount of time or would you prefer to see an acknowledgement that your bug will not be fixed at which point you can either shrug your shoulders or make a stronger case for why the bug should be fixed? As was mentioned before, very much the former. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: style guide proposal
On 12/19/2013 10:20 AM, Andrea Marchesini wrote:
Hi,
Writing a patch for bug 949488 I had to indent this piece of code:
nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
if (NS_WARN_IF(NS_FAILED(ssm->GetSimpleCodebasePrincipal(
originURI,
getter_AddRefs(providedPrincipal) {
It seems that our style guide does not say anything about how indent this
tricky case.
So, talking with bholley we decided to write an email proposing something like
this:
1. if they can, all the params on the same line. max 80 chars.
2. otherwise multiple lines, aligned with the beginning of the params list.
es: obj->ThisIsALooongNameMethod(longParam1,
loogParam2);
3. if 1 param alone goes over 80chars, it must be aligned in order to stay in
the 80chars and the rest of the params must be aligned with it.
nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
if (NS_WARN_IF(NS_FAILED(ssm->GetSimpleCodebasePrincipal(
originURI,
getter_AddRefs(providedPrincipal) {
// 80chars here ^
This approach is already used in dom/workers and IndexedDB.
https://mxr.mozilla.org/mozilla-central/source/dom/workers/RuntimeService.cpp#1647
I would suggest:
| nsIScriptSecurityManager* ssm = nsContentUtils::GetSecurityManager();
| rv = ssm->GetSimpleCodebasePrincipal(originURI,
|
getter_AddRefs(providedPrincipal);
| if (NS_WARN_IF(NS_FAILED(rv))) {
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: On the usefulness of style guides (Was: style guide proposal)
On 12/20/2013 10:55 AM, Neil wrote: Brian Smith wrote: In PSM, we created some scoped pointer wrapper types around NSS data structures (ScopedNSSTypes.h), which are based on the MFBT scoped pointers. And, consequently, PSM has standardized on MFBT smart pointers throughout the module (there should be nsRefPtr in PSM, only RefPtr, for example). Yet, most code in Gecko is based on the nsCOMPtr-like smart pointers (nsAutoPtr, nsRefPtr). I don't know how big of a deal this is, but this is the type of thing that would need to be resolved to have a consistent style throughout Gecko. I thought that it was pretty clear which smart pointer to use: nsCOMPtr - interfaces nsRefPtr - concrete types that inherit from nsISupports RefPtr - everything else (i.e. no QueryInterface) That makes it quite clear it isn't clear: nsCOMPtr - interfaces nsRefPtr - concrete types RefPtr - code imported from WebKit HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: List of deprecated constructs [was Re: A proposal to reduce the number of styles in Mozilla code]
On 01/07/2014 01:11 AM, Joshua Cranmer 🐧 wrote: On 1/6/2014 6:06 PM, smaug wrote: On 01/07/2014 01:38 AM, Joshua Cranmer 🐧 wrote: On 1/6/2014 4:27 PM, Robert O'Callahan wrote: That's just not true, sorry. If some module owner decides to keep using NULL or PRUnichar, or invent their own string class, they will be corrected. Maybe. But we also have a very large number of deprecated or effectively-deprecated constructs whose deprecation module owners may not be aware of because their use is somewhat prevalent in code. For example, the NS_ENSURE_* macros are apparently now considered officially deprecated. Since when? NS_ENSURE_ macros are very useful for debugging. (When something is going wrong, the warnings in the terminal tend to give strong hints what/where that something is. Reduces debugging time significantly.) Since Benjamin's message of November 22: <news://news.mozilla.org/mailman.11861.1385151580.23840.dev-platf...@lists.mozilla.org> (search for "Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS" if you don't have an NNTP client). Although there wasn't any prior discussion of the wisdom of this change, whether or not to use NS_ENSURE_SUCCESS-like patterns has been the subject of very acrimonious debates in the past and given the voluminous discussion on style guides in recent times, I'm not particularly inclined to start yet another one. FWIW, I've never seen much support for this change from anyone else than Benjamin, and only in his modules the NS_ENSURE_* macros have been effectively deprecated. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
On 01/07/2014 01:46 AM, Jeff Walden wrote: I don't think most JS hackers care for abuse of Hungarian notation for scope-based (or const) naming. Every member/argument having a capital letter in it surely makes typing slower. And extra noise in every name but locals seems worse for new-contributor readability. Personally this doesn't bother me much (although "aCx" will always be painful compared to "cx" as two no-cap letters, I'm sure), but others are much more bothered. Based on the discussion in #jsapi yesterday, I'm not sure that "most JS hackers" is necessarily accurate. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers
On 01/18/2014 08:51 PM, Matthew N. wrote: Hello, What does it mean to be a "Preferred Reviewer" (previously called a "peer") in a Toolkit sub-module[1] and not be on the list of Toolkit Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this case. Specifically: 1) Can a "Preferred Reviewer" review code in the related submodule without oversight from the sub-module owner? 2) Is a sub-module "Preferred Reviewer" considered a "Toolkit reviewer" for the purposes of [3]? In general, all reviews should be done by peers, so people who are not peers should not be listed as preferred reviewers. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ISomething, nsISomething or mozISomething?
On 02/17/2014 03:15 PM, David Rajchenbach-Teller wrote: Do we have naming conventions for new xpcom interfaces? I believe that I have seen all three forms on the tree. I need to pick one for my new bug. Which one should I pick? For C++ interfaces, namespaced IFoo or Foo. For XPIDL interfaces, as they're in the global namespace, we still tend to prefix, so I guess nsIFoo. (Not cross-posting to ask.m.o until it supports persona.) HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New necko cache?
On 02/21/2014 12:01 AM, Honza Bambas wrote: On 2/20/2014 10:25 PM, Neil wrote: Well, that was confusing. The old contract ID was @mozilla.org/network/cache-service;1 The new contract ID is @mozilla.org/netwerk/cache-storage-service;1 Turns out that there are two differences, not one. Yes, forgot to mention, sorry. Hoped it's obvious from looking into the IDL file. Why do you take this as "two differences"? netwerk vs network HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement (and ship?): canvas context "alpha" attribute
On 03/12/2014 08:40 AM, Rik Cabanier wrote: *Link to standard:* http://wiki.whatwg.org/wiki/CanvasOpaque That's not a standard... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: Web Activities for Android
On 04/15/2014 11:08 PM, Joshua Dover wrote: as this current specification is not on a standards track (and will probably not be compatible with what we have now). That sounds like a clear "no" to me. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Query about MimeType objects (was Fwd: Intro email)
Hi Chris, The spec might: <http://www.whatwg.org/html/#dom-navigator-mimetypes>. HTH Ms2ger On 05/12/2014 12:18 PM, Chris Mills wrote: Hi all Dann (see below) had a query about the MimeType objects returned by NavigatorPlugins.mimeTypes. Does anyone here have any advice about dealing with those? Chris Mills Senior tech writer || Mozilla developer.mozilla.org || MDN cmi...@mozilla.com || @chrisdavidmills Begin forwarded message: From: dann Subject: Intro email Date: 3 May 2014 04:10:55 BST To: cmi...@mozilla.com Hi Chris, It was lovely meeting you at FITC and sitting next to you over speaker's dinner. Here's that page I mentioned that has external links which now go to a domain squatter: https://developer.mozilla.org/en-US/docs/Web/API/NavigatorPlugins.mimeTypes In Chrome, at least, those mime type objects behave in a terribly strange fashion. I haven't found anyone who can describe it sensibly, but they seem to generate a new object on every access, which means if you're trying to walk the tree without going in a loop you'll have to write a special case for them, because there's no way to detect that you have seen it before. I'd love to get the straight dope from the horse's mouth though, so if you learn anything interesting about them please do pass it along! Thanks, Dann Toliver http://bentomiso.com http://bentobox.net http://daimio.org ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Argument validation as a JSM?
On 05/15/2014 05:58 PM, ajvinc...@gmail.com wrote:
Re: readability, that's something to think about, but when I write code like
this:
if ((typeof num != "number") ||
(Math.floor(num) != num) ||
isNaN(num) ||
(num < 0) ||
Math.abs(num) == Infinity) {
throw new Error("This need to be a non-negative whole number");
}
Well, it adds up. :) Even now I can replace the fifth condition with
!Number.isFinite(num).
>
One could use "if ((num | 0) !== num) { ... }". That should be
equivalent for 32-bit unsigned integers.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Standardized assertion methods
On 06/02/2014 01:49 PM, Mike de Boer wrote: Yes, that’d be very nice to have! In a perfect world, all the test suites/ runners we have end up using the same assertion methods. This would indeed greatly improve the portability of individual tests. As I said before (but was ignored), the more sensible approach to achieve that goal would be to adopt the testharness.js methods, which are also more consistently named, have better behaviour for the shorter-name methods, and are documented more clearly. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: navigator.deviceStorage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dave, There exists a template [1] for this kind of email. Using it makes it much easier to be sure the important questions are addressed. You're missing the answers to all questions except the bug number. (That bug, I should note, will need to live in a Core::DOM component if it's going to have DOM changes. Firefox OS::General is not the correct product for changes to Gecko.) On 07/17/2014 03:08 AM, Dave Hylands wrote: > Currently, we have navigator.getDeviceStorage and > navigator.getDeviceStorages > > We're looking to expand device storage to add support for more > virtual storage areas, like DropBox, or GoogleDrive, etc. See bug > 1035053 > > I was going to propose that we add navigator.deviceStorage (or > possibly navigator.mozDeviceStorage) and have at least the > following methods: > > deviceStorage.addObserver deviceStorage.removeObserver > deviceStorage.getAll deviceStorage.getDefault > > We need some new notifications, one to report when the default > volume has changed (on B2G it is controlled by a setting which then > gets reflected into a preference), one to report when a new storage > area (like DropBox) is added, and one to report when it goes away. > Presumably we'd also need additional APIs to actually add/remove > storage areas. > > deviceStorage.getAll would return exactly what > navigator.getDeviceStorages returns today, and > deviceStorage.getDefault would return exactly what > navigator.getDevicetorages returns today. There's a typo somewhere here. > I think that we probably need to leave getDeviceStorage and > getDeviceStorages both around for the time being in order to > maintain backwards capability. > > So I guess I'd like to determine if the approach I've outlined is > reasonable, and I'd like to get an opinion on whether we should > use deviceStorage or mozDeviceStorage. The policy [2] is crystal-clear: we don't add moz prefixes, period. HTH Ms2ger [1] https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement [2] https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Guiding_Principles -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTx4/HAAoJEOXgvIL+s8n2V1QH/j8wkl7nnJHtN1Djm+pbZKlV Q8xjxkLvLHRxTjqtXGAUHWLX7I7z2GVC8UbqbKGmRT3JxOvrY2G6vzSnrcVBjeJ9 l5ZfSZNUFpk4w9krjT4tAG2s3EPHffzQqxqmeNwrzd3Pl19jzCHmvCtX5fotaK+y XBaZ6vlMj2LZ5+pwSX2/m/CoWATP1J2kOdoukWso6Wzv1o7c7rw6yP/JJ8HSVYW2 wUPhiJc8LuglXyJyCJMRJllq7qu9UZ9iCMTHrmeAr6sxfTWaYHL2CSZQ6phgg9Yk jodLCSl/qPQ7SlOUcS87ACFpfkncDclvvd3FpYRhN9hD0rMOphdA+8I50ry/LDs= =iKpo -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: External dependent tests in gecko and gaia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/14/2014 08:22 PM, Edwin Wong wrote: > > I think we're all in agreement. Adding support for manifest and > mach/make option with the specific directory makes sense. To > summarize: > > * land tests in a directory name "external" so it's easily > identified as needing external access. I don't think anyone is in agreement with this, actually. The suggestion was to use a manifest annotation *instead of* the unnecessary directory structure. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJT7QmWAAoJEOXgvIL+s8n2sQYIAJFNcZul6cQjWQ6oMGTpfDta 5tyGAnwRBMmsStVaJzrfAsBoN7aZp3Z+1rjo4Kg5hutUUvkqWyAwVf1xZ+tUYa8T NLH+P7Yqg33hH8FcaNX+5P7zqFofG89bxkl5QTbgIlFXDbafaaWoz9T3s42T62fQ 2zuG8mYOD+h1leMTd9WqcYZtMWxMb9X+07XUxViLa5sfArYSmmtEp1Kxf2mEZGvq Fh+JcBdN9OU2IaVzzUu5n3nBWUg3JfAjM8jx6u/ShxlqlgxBCq4HvNzsX3+ZNHIi lpawAEHLMU/chxjI43tUNFM+CDKfy3oQxXn6n7tNj0P1hFBLwkz/4dNjQ9Gj46s= =qMFQ -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Touchpad event
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/11/2014 08:18 AM, Kershaw Chang wrote:
First of all, you neglected to explain the standardization situation
here. Is this feature being standardized? If not, why not? How do
other browser vendors feel about it?
> +interface TouchPadEvent : UIEvent { + [Throws] + void
> initTouchpadEvent(DOMString type, + boolean
> canBubble, + boolean cancelable, +
> WindowProxy? view, + long detail, +
> short button, + boolean ctrlKey, +
> boolean altKey, + boolean shiftKey, +
> boolean metaKey, + TouchPadList? touches, +
> TouchPadList? targetTouches, +
> TouchPadList? changedTouches);
Regardless of whether this feature is something we'd want to
implement, we most definitely shouldn't introduce new init*Event methods.
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJUEVzEAAoJEOXgvIL+s8n2YWYH/i9h3e3GvQ9dPrYYg72F/mdD
BXdyHiyKarz4dSI8H0UJHwDhCtBKi92AskHhCeT3l4KX4h7pX87144LYNYiZ9qzv
rMXDFvf5Oo8M4uaEPo82z1M2OW6jADuFCfs4SeK+1aqW5DLRRMlYiGfop4yeGp+g
m81ciytaLr08ro6+K+HgIP/zCo5KLtvp54kGLRg0EMqWnNE4SxG8Nrvm/xe65udz
+3z21DhapAu8jMFhJ2JeAy+0ivu0pnCm0JUXiLmOCmzweSlO1w3Qr5KGwWqS9qjA
6k74T7+Pp95cFgELK03IvhWyQCHNLhPdH/qJex59jF2i7N9SV47FGMOq8wjLFBU=
=UeuN
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: HTML5
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 09/20/2014 02:23 AM, L. David Baron wrote: > W3C recently published the following proposed recommendation (the > stage before W3C's final stage, Recommendation): > > http://www.w3.org/TR/html5/ HTML5 > > There's a call for review to W3C member companies (of which > Mozilla is one) open until October 14. > Many things could be said (and have been said in this thread) about the HTMLWG and whether this work is useful. However, given that I expect any objections from our side to be ignored at best and lead to you being pressured to retract them at worst, I believe the answers that make the most sense are * Regarding the HTML5 specification, my organization: abstains from this review. * My organization: does not expect to produce or use products or content addressed by this specification HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUH8u7AAoJEOXgvIL+s8n2NUkH/A613tpVUV1jUcnQwumQFcSP kBou9BPQqT6tr/bse2YdljnnqtcvJHi7eFO+yocfJfEwuGFuIWgsxHe5CeuDRLUw SOweot5onCUxsLZwiHx++oYK7TVKb8E2HL7FArtbhmBL4SnDS7FWw5kwHQXh3RiI Nc2YyZ6ETyiJL2DE8ym2o1wyrVRS4xjB0kiY4ADSxAMYJ5JAqd4o94kIrDIAAa8Q e5XoqhylEBJQc1Gdn/7JQGcynL4SpSWQzMzO7oNd0okxbUJs1arrSJGN4lYvwV+r UX8s2MzN3i+fEjPzohBbJxxhmZXBumFY+EZ3xGq773Fmw/Wbv1NoTkzlElYqQJs= =Yd1M -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documenting uses of Github at Mozilla
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/2014 05:59 PM, Ralph Giles wrote: > On 2014-10-01 7:17 AM, Mike Hoye wrote: >> Having to scramble to recover from data loss - particularly >> around source or bug tracking - is a miserable experience we >> should try to avoid. > > Perhaps http://gitmirror.mozilla.org/ should be our project > directory. Looks like the instructions to add repos are on intranet; why? Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJULCydAAoJEOXgvIL+s8n2+0MIAJKuWFkVTXpNwdirhBY+P/Zj 4yE8U3SAwzYoG+rTWpqozUeGQDhtDKlxM9VsKyRDdVKR+co2O+Eno1yhJjYDp0EI ejcTJbEX6IeaZ23svGQBN0VOEoWrmaGcSvWHivFejjXGU8FIhbP09zlg51IPvu33 iLH18v2Sj3360ecsNaRFmc50kvYtfX/0gbU9eI+Elhzx9LtWJ4LcX5CcX6a3Y3Io A/TKuIkiJOxS5QGj115EwByoE1tMGf14yollhBDsYkQ6jEVI9fudMTFORHHyuW++ TCAqku2pr5dULI8+/8fRPmPgWivFK3SnqcIWdgM2M/XW+JBNaRjChVDiPBwpjAs= =p3// -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Breakdown of Firefox full installer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/14/2014 02:09 AM, Kyle Huey wrote:
> The simplest way to break the installer down is by the files in
> it.
>
> e.g. http://khuey.pastebin.mozilla.org/6781501
For future reference:
> mozilla@KHUEY-19294 /c/dev/scratch $ wget
> ftp://ftp.mozilla.org/pub/firefox/releases/latest/win32/en-US/Firefox%20Setup%2032.0.3.exe
>
>
- --16:59:06--
ftp://ftp.mozilla.org/pub/firefox/releases/latest/win32/en-US/Firefox%20Setup%2032.0.3.exe
> => `Firefox Setup 32.0.3.exe' Resolving ftp.mozilla.org...
> 63.245.215.46, 63.245.215.56 Connecting to
> ftp.mozilla.org|63.245.215.46|:21... connected. Logging in as
> anonymous ... Logged in! ==> SYST ... done.==> PWD ... done.
> ==> TYPE I ... done. ==> CWD
> /pub/firefox/releases/latest/win32/en-US ... done.
>
> ==> PASV ... done.==> RETR Firefox Setup 32.0.3.exe ... done.
> Length: 35,285,328 (34M) (unauthoritative)
>
> 100%[>] 35,285,328 967.16K/s
> ETA 00:00
>
> 17:00:07 (617.58 KB/s) - `Firefox Setup 32.0.3.exe' saved
> [35285328]
>
> mozilla@KHUEY-19294 /c/dev/scratch $ ls Firefox Setup 32.0.3.exe
>
> mozilla@KHUEY-19294 /c/dev/scratch $ 7z x Firefox\ Setup\
> 32.0.3.exe
>
> 7-Zip 4.42 Copyright (c) 1999-2006 Igor Pavlov 2006-05-14
>
> Processing archive: Firefox Setup 32.0.3.exe
>
> Extracting core\precomplete Extracting core\removed-files
> Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}\icon.
>
>
png
> Extracting core\browser\chrome.manifest Extracting
> core\browser\components\components.manifest Extracting
> core\browser\searchplugins\amazondotcom.xml Extracting
> core\browser\searchplugins\bing.xml Extracting
> core\browser\blocklist.xml Extracting
> core\browser\searchplugins\eBay.xml Extracting
> core\browser\searchplugins\google.xml Extracting
> core\browser\searchplugins\twitter.xml Extracting
> core\browser\searchplugins\wikipedia.xml Extracting
> core\browser\searchplugins\yahoo.xml Extracting
> core\defaults\pref\channel-prefs.js Extracting
> core\application.ini Extracting
> core\browser\crashreporter-override.ini Extracting
> core\crashreporter.ini Extracting core\platform.ini Extracting
> core\update-settings.ini Extracting core\updater.ini Extracting
> core\webapprt\webapprt.ini Extracting core\crashreporter.exe
> Extracting core\firefox.exe Extracting core\uninstall\helper.exe
> Extracting core\maintenanceservice.exe Extracting
> core\maintenanceservice_installer.exe Extracting
> core\plugin-container.exe Extracting core\plugin-hang-ui.exe
> Extracting setup.exe Extracting core\updater.exe Extracting
> core\webapp-uninstaller.exe Extracting core\webapprt-stub.exe
> Extracting core\AccessibleMarshal.dll Extracting
> core\breakpadinjector.dll Extracting
> core\browser\components\browsercomps.dll Extracting
> core\D3DCompiler_43.dll Extracting core\d3dcompiler_46.dll
> Extracting core\freebl3.dll Extracting core\gkmedias.dll
> Extracting core\icudt52.dll Extracting core\icuin52.dll
> Extracting core\icuuc52.dll Extracting core\libEGL.dll Extracting
> core\libGLESv2.dll Extracting core\mozalloc.dll Extracting
> core\mozglue.dll Extracting core\mozjs.dll Extracting
> core\msvcp100.dll Extracting core\msvcr100.dll Extracting
> core\nss3.dll Extracting core\nssckbi.dll Extracting
> core\nssdbm3.dll Extracting core\softokn3.dll Extracting
> core\xul.dll Extracting core\dictionaries\en-US.aff Extracting
> core\freebl3.chk Extracting core\nssdbm3.chk Extracting
> core\softokn3.chk Extracting core\dictionaries\en-US.dic
> Extracting core\browser\omni.ja Extracting core\webapprt\omni.ja
> Extracting core\omni.ja Extracting core\dependentlibs.list
> Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}\install.rdf
>
>
Extracting core\webapprt
> Extracting core\uninstall Extracting core\dictionaries Extracting
> core\defaults\pref Extracting core\defaults Extracting
> core\browser\searchplugins Extracting
> core\browser\extensions\{972ce4c6-7e08-4474-a285-3208198ce6fd}
> Extracting core\browser\extensions Extracting
> core\browser\components Extracting core\browser Extracting core
>
> Everything is Ok
>
> mozilla@KHUEY-19294 /c/dev/scratch $ rm Firefox\ Setup\ 32.0.3.exe
>
> mozilla@KHUEY-19294 /c/dev/scratch $ find . -type f -printf "%s@
> %p\n" | sort -nr 25027184@ ./core/xul.dll 11174488@ ./core/omni.ja
> 10397296@ ./core/icudt52.dll 8930647@ ./core/browser/omni.ja
> 4877424@ ./core/gkmedias.dll 3715184@ ./core/mozjs.dll 3231696@
> ./core/d3dcompiler_46.dll 2106216@ ./core/D3DCompiler_43.dll
> 1803376@ ./core/nss3.dll 1023600@ ./core/icuin52.dll 897688@
> ./core/uninstall/helper.exe 800368@ ./core/icuuc52.dll 770384@
> ./core/msvcr100.dll 684984@ ./setup.exe 638064@
> ./core/libGLESv2.dll 622592@ ./core/dictionaries/en-US.dic 421200@
> ./core/msvcp100.dll 413296@ ./core/nssckbi.dll 331376@
> ./core/freebl3.dll 275568@ ./core/firefox.exe 273008@
>
Re: PSA: content/{base,html,media,svg,xul} will move to dom/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/2014 01:12 PM, Kyle Huey wrote: > On Sun, Oct 26, 2014 at 3:09 AM, Birunthan Mohanathas > wrote: >> This has landed on inbound and will probably be merged to central >> on Monday. >> >> To update existing patch files to use the new paths, see: >> https://gist.github.com/poiru/b266b75473a8d9f71d33 > > Did we not coordinate this with the sheriffs at all? This needs to > be merged to all trees as soon as possible to keep the merge pain > down. Philor merged to m-c and fx-team, fwiw. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUTTsBAAoJEOXgvIL+s8n2u/wH/3mYHYLyAkDn8g9olvV92D1U QFO9Encqz/dc28DcYBbO9+ZYzw/Q606aqGO4v4F90+5/7ipC9YTvUURS3qBO19QG 0IAREtnFKOGNUKYkZqNfhSG+0+8onmwK3voxLuespr88uvxdq7gVx9TxM9KtuET+ jQz1dpOPj/O3I2V/MZb6usHd4CbnG+JQ0JgC5U/Gr4uNqL+YivRBwOgrgvWPzXoR nBEdap4WdUmICVMTcCSn3XtSA8Pp1EtyWTfTivHfZcqehdOtVs7VthN3CJR+umNL rO29BxY8bTdBFl7YsdJZBHJ5H/0AIktJs6hTBDfKdRjR3H2oytn7wb6YNqK9GeA= =S5U7 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/23/2014 12:45 AM, Ehsan Akhgari wrote:
> On 2014-12-22 6:35 PM, L. David Baron wrote:
>> On Monday 2014-12-22 18:21 -0500, Ehsan Akhgari wrote:
>>> On 2014-12-22 6:07 PM, L. David Baron wrote:
>>>> On Monday 2014-12-22 17:54 -0500, Ehsan Akhgari wrote:
>>>>> On 2014-12-22 4:56 PM, L. David Baron wrote:
>>>>>> I think removing implicit conversions to T* will make a
>>>>>> lot of code in the tree uglier (".get()" everywhere).
>>>>>> That might, in turn, encourage people to do worse things
>>>>>> to avoid having to write .get() everywhere; it's worth
>>>>>> thinking about what those things will be.
>>>>>
>>>>> Do you have any examples of those bad things? (FWIW I'm
>>>>> all for making bad things impossible.)
>>>>
>>>> * using raw pointers instead of smart pointers
>>>
>>> I am planning on making that impossible [*] in 2015.
>>
>> I presume you mean making direct calls to AddRef and Release
>> impossible, and not raw pointers in general.
>
> Well, I did pick that project up but for some reason it was never
> finished (don't remember what.) But that's not what I was talking
> about. See bug 1114683 for an example of what I was talking
> about.
It was finished, and then reverted. For reference:
<https://bugzilla.mozilla.org/show_bug.cgi?id=666414>,
<https://bugzilla.mozilla.org/show_bug.cgi?id=710473>.
HTH
Ms2ger
-BEGIN PGP SIGNATURE-
iQEcBAEBAgAGBQJUmR8xAAoJEOXgvIL+s8n2OlcH/Am6t8XxPCvZj3w/VWbPbhF8
wQRqfnWvdHwB/neOxaTzcyMWL1siQfQIHTmDjOKmbKtD6tETyybuYiWba6YmRjFQ
52URtbQkh5zRS6VawRyNEiMc3ea6gnj+TPQ9jOOgO0556wjN+CoqwWAXvcFz6mhC
AQVVh+Cm9mvo3VRJcmzFbQ6lwuIaUOruIoDE8vy8fQVKC1vYgIxntKgfpcLQIe0Z
2Oux89uN3xJOl9i+JZevUkOrdFO7tZg2LduS7YcdCg9WFZy1PNIKcLxnGLi8V1Nv
JkwEX+YpkgV/whI6etk4D7nzWT+ZDRYVEsPrZlRRf8Lph9dM0kP3y15H7pEY9Q0=
=fIbp
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Sub-resource Integrity (SRI)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2014 06:40 AM, Francois Marier wrote: > Summary: Allow web authors to add integrity checks to > sub-resources. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 > > Spec: http://www.w3.org/TR/SRI/ What's the testing story? Do we pass the web-platform tests (<https://github.com/w3c/web-platform-tests/tree/master/subresource-integrity>)? Do we run them in automation? Do we intend to extend the tests to a level where we can be confident about interoperability with other browsers? Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJUo7bvAAoJEOXgvIL+s8n263wH/jvKXiWFUdTKEh08xCX5RmrL zg40EavKlDf7oG5B0jdusUqy3UiWWeR81hmGEW3nYaCCsc6tVwKpdSU7oj/11Sev /Tncx6bqrUZJlpbC8crcdtyoVaxZEk1RFGE+U2tLGG1D/QPr3Dc08T0CsYqhdFWS ifd0J36ziDh6nUHFiPsIt7sLdfhuRQefAzI1gtqi9QgwHNuIOotj+IH0zRoWASEX 9U2Oc46F6UQk5h8/Y08+WFiWi/wuPCmn38Az85GBPhiDm2Ewe+L6+tadRu1SULjo nO63y1z+IvWxyuK+a5tBSXeaUWaMTRPiPRC0dwPyOwfm4S4OdC5mzn/D+xhGZVQ= =8sup -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [dev-servo] UI Workers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/20/2015 09:12 PM, Jonas Sicking wrote: > On Fri, Feb 20, 2015 at 8:11 AM, Julien Wajsberg > wrote: >> Le 20/02/2015 04:25, Robert O'Callahan a écrit : >>> On Fri, Feb 20, 2015 at 4:02 PM, James Long >>> wrote: >>> >>> Personally I think what we *really* need to be working on is >>> making all of the DOM APIs asynchronous. That's what Servo >>> needs anyway. That's a step in the right direction for #3, and >>> we can see much more we can get out of the main thread after >>> that. >>> >>> I don't see how making DOM APIs asynchronous really helps you >>> achieve #3. There are some specific cases where custom layouts >>> need to repeatedly measure content, that currently rely on APIs >>> that trigger multiple sequential synchronous reflows, which >>> would be better served by less synchronous APIs. We have >>> nebulous plans for addressing that (it's not as easy as "make >>> everything a Promise"). But those aren't the main problems >>> mobile Web apps face right now AFAIK. >> >> In Firefox OS development, this is part of the biggest issues we >> have for very specific tasks. > > To be clear, we're not talking about making the whole DOM async, > right? > > I.e. we're not talking about adding an async element.appendChild() > or an async element.innerHTML? > > What we're specifically talking about are async functions for > getting layout information? So async element.getComputedStyle() > and element.getClientRects()? These are particular cases that have been suggested, yes. (I've heard suggestions for async innerHTML too, but I don't think that was in the context of Servo.) Either way, while some people have been dreaming about such APIs, we're not actually working on any, or planning to start working on them. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJU57l9AAoJEOXgvIL+s8n2jQMH/1e+/4FTpq/r/7qTJ5MEQ0mL T1MbR+oVBr6xDCX4hu72ZCarmEC992coPnuMC4Y8NI4gD91XpAZhToFraGifXC4Z zEJaqYfUSH8YRMIbwqmH49j1aEQjLW/q0XwHfsE3M7V4+7P7BaccQhotSQQz5Ubo +SGtPbqfTmQr4FeZhXGCOGJAU76tBAdoKr0NanDh6FvuiIz/vB+ZVUSStsK2gwYw FbIdXBPiJLlbW+VQjSz4NDXLrLIfzZ7jb5t43Ad0ljMeKltNSh3X6ad8Wv6DTExM RHx6xGojSYhEvwelfbMhsxI2zCmNrxHoJ2sBSmnG+2kr5BDaUP1c/jneD5zH/Vk= =EYaK -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement and Ship: UI Events (formerly DOM Level 3 Events) EventModifierInit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2015 03:27 AM, Masayuki Nakano wrote: > EventModifierInit is a dictionary to initialize modifier state at > creating untrusted event. This allows to initialize "AltGraph", > "CapsLock", "Fn", "FnLock", "Hyper", "NumLock", "OS", > "ScrollLock", "Super", "Symbol" and "SymboleLock" state of creating > events and it has been no way to initialize them. > > Currently, we don't support "Super" and "Hyper" modifier state > yet. Therefore, we don't support modifierSuper and modifierHyper in > this time. > > Bug to implement: > > Support D3E EventModifierInit > https://bugzilla.mozilla.org/show_bug.cgi?id=1124608 > > Link to standard: > https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#h-event-modifier-initializers > > > What are other browsers planning to do? Do we have any tests in wpt that could show interop? - -- Thanks Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVJi0jAAoJEOXgvIL+s8n24DEH/3t5ERyZe5gFLLoDzIsu5plq 8YuNpZC4geIFzerTHn0iF5pSx1+se0+y0eDmpf4V5WOElWgxdsI++4Zsugu/tu8+ z9SxBNcKIuO06NhsnBj60OpE9nuzHXx1fOlqSTcj3PLS4V8tLFjDlA7zb7Wy3E1+ nPIuanFymTZExJu8ZLJkzcrqfUzW/gCgBmPES76uwjTNX+79tmowdwC2Hwntakbn aRNMavc+YmQyEupq6PWtFynHvJW/JO6jDa2hCt/mWprrbSADvP+dfZc3VKcuEMoi /tvzQx8qjzALRSvv4M5AF80r1YaLO1MX0+GiKn/2XJXuCWl5x9IueM09MlfjnOc= =dPoX -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: mochitest is() now uses ===
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, Bug 949614 landed yesterday, making the is() function in mochitests compare its argument with === rather than ==. is_loosely() has been introduced (hopefully temporarily) with is()'s old behaviour; ise() is now simply an alias for is(). Thanks to everyone who helped bring this home! Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVLhlwAAoJEOXgvIL+s8n27TEH/RTBfCQmN0dwDzzRGPsYT9ya ztmFfpJq2NKe85YX9XnO+yLha9Lvc2V83J4SHRC0PpJgKEfgR3DAswCDnX+MOD3e 7PfXqkY6ceVhrrPz1b0TxWWCnVvW9OyjlxhAjH7k8K96T0uBvcrB3q0AKFLC4aXH RhzHWGxnaP1jzG1JIpLbVELobBXTuKDHOA4jnEMpaksrgttrVzk1b4gnaJF/CuMF mhFM0x1hKR/0dS3XKF9XAFMmbErRh9b9lOzg5s87+dGXyEkJg7POT7ozCFn6WHDb ehRvtFqgtHLeqM62IAwk1t9XmqZvP/rvrBQECbR7MRqfmomTtzdKw+BuO2867qY= =YIyD -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Excessive inbound bustage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/21/2015 06:07 PM, Eric Rescorla wrote: > On Tue, Apr 21, 2015 at 8:39 AM, wrote: > >> On Tuesday, April 21, 2015 at 3:03:37 AM UTC-5, Gabriele Svelto >> wrote: >>> On 21/04/2015 08:25, Gabor Krizsanits wrote: >>>> Maybe because I usually work on core, and such confidence is >>>> hard to >> reach >>>> there, but I'd like to think at least a try run that check if >>>> the patch builds on all platform and a full test run on at >>>> least one platform is >> not >>>> too much sacrifice of ones time. >>>> >>>> Personally I think that "my time" is cheaper than "everyone's >>>> time". >> It is >>>> slow. It is annoying, but holding up ALL the other >>>> patches/developers >> is >>>> expensive hence a risky option. So I suggest everyone to be >>>> very conservative about that confident feeling. >>> >>> I agree; since I work mostly on patches that are relevant for >>> FxOS/B2G I always run a try build across all architectures >>> before to ensure it doesn't break anything else. Somehow I was >>> under the impression that everybody did that. >>> >>> Gabriele >> >> I think this should be standard procedure for anyone working on >> platform. A push to try for a base set of builds (mac, linux, >> win, b2g ics) plus a good set of tests (usually for me it's >> mochitests) covers things. Once those mostly complete I can mark >> the bug with check-needed and walk away, tree drivers will handle >> the landing when inbound is open and green. > > > Isn't the point of inbound supposed to be that it's safe to land > even without 100% confidence? Here's the guidance from the Wiki: "without 100%" doesn't mean "with 10%", which is what it feel like nowadays. Tryserver time is machine time; inbound bustage is people time, and the latter is much more expensive. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVNndkAAoJEOXgvIL+s8n279YIAJ+t5zHBzNGUuPCUmvG85s4Z b45iDaMbE06OfN4mNGOc1zAU61qonNszqLmLatzrK03BQXoqCRJRGRiWoHAQnOLN zHUS2u6T/UA6REbFBJyJmOqFx7Xd93RnbFUHOPLc/zQcUNwobr8pm/tjnfPxLuju X0cdtFtSr1O0a968+q/BYpbARH4KTJhJGxSoVtaKIQx4Gp3xPW3TZwiTT3OdtLeW AGFQj2TOoAEOyxUvyawfMbAr5WPe6dwPdlE0GH8L+mDmSZERo15KBz44SywK719y 0cE1+yw13pVb8CNA1uKY6rDqWxiIYxPs4CEvM3KFMulb0HZl/vh7qCMtDZ+GuHY= =D0/Q -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to remove: mochitest- mach commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/13/2015 09:54 PM, Andrew Halberstadt wrote: > As mentioned previously in another post, work is under way to > remove the flavor specific mochitest commands (e.g mach > mochitest-plain, mach mochitest-browser etc.). > Does this include `mochitest-1` and friends? These are a lot easier to use than having to figure out the exact incantation for the chunked suites. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVU7vsAAoJEOXgvIL+s8n229EH/A+dFtY8nqDOCywDGBjgU8cL V32tfYfv3tISII8YCP9Jsl58SW3YFpUk+inneUdVKXYce5OAkr4furpE64JbA7Kq RInF56lkdKagTvJyKS8VPsTHZ/kEOGFAfSPDD3pxlUjsZgqwuBxwtUPLR7NkLkWx /xViL9ZNqgXiveWPsrpYKDEYqxVgmm9/XNVCqXX8R0z3r3jI4BWCXiwjb5ELE7sD S5sqknCBezlO2WYNUG4Fir8hRlESjQeJtqoCfhJ2x1MJotRWoGCuk4ktEU6QIYRS zmeY/3miXbpUOhqNSCC/CFasRcF9jLwzs8OQChFTMDW3DMSMDgtdNj1xx+FV9z4= =C348 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: User timing API in workers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/2015 07:16 PM, Andrea Marchesini wrote: > Summary: user timing API in workers. We already have this API > exposed to main-thread content but it's nice to have it also in > workers, shared workers and service workers. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1155761 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1158032> > > Link to standard: http://www.w3.org/TR/user-timing/ > > Platform coverage: all platforms > > Other browser support: not in workers as far as I know. Please file a bug on the spec to add it (even though this is the webperf wg), and keep it out of release builds at least until it's been discussed there. Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVXf7hAAoJEOXgvIL+s8n2ON4H/joOtkdA6pAqsEJmFZebZmZH CND5saMByYUx78y9eH81PWFVzthDqPAcQJ1aowkLjn6PoWQ2wzvIXs1dF4zzBwyu UjXeFPyGr+DNL9R+r6m4VEO0w8pA/GcQLvJ33j71FwCrPBTlh7O9oxFUFgaGATpe zz5qgyXgB31BI0WI4/SRaC6xl0As1GcDRqBMkMl82H1ERVfvPe+KXhwy6zMuhdji wXzneG0AJ5F5ykx50SXJe1kVRd7WnVnhAIyYvlFDXibObqvYJkqpQl+gvddKH8VU zynPqtjBEdWTsmd9VudaGuSiCL7q/+/RY/6XKCI9PK+IXF4gL4Mv8KA6qz8SmGc= =lT67 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Rust and Servo training sessions at Whistler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/22/2015 05:51 AM, J. Ryan Stinnett wrote: > On Sched, it appears the Servo session is scheduled for Friday, 1 - > 3 PM, is that now the correct date and time? That's correct. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJViDGBAAoJEOXgvIL+s8n2NEkIAIYOnyVYXpcMex00o9zbNXkk Kx+2AztGfUMEjLR55CfURxjlBD6vx/4RTCAPexiV9WoGlH4Goy/fPWwKfy2bkito 67vh3QViYsc6BD2ea6NoVpF1wOQurFTxv5owmSF7ML6NEKWFBtphmhIxggEr0WY/ OiexS4k6iiLwlDT/2+pl9xjxb1IjBn45wF0FhiHlfrE95EuFGmhYvYJZkIJ9pTlX do/4Q1Mbr1lEuZEUdaqh4gxs+dHg3AovXRNiAnmsH1bJpsEzR6PqRw30qQv2mBTB NfeMXFYC437a1EYlzE3lS4Nvu6dturwTSKpBRiOCDN2HUtMVt+9khZMu7qYUkNI= =6acZ -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: web-platform-tests on debug builds running on try
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/01/2015 01:35 AM, James Graham wrote: > Web-platform-tests are now running in debug builds on try only. > \o/ Thanks for getting this up and running! Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVk5APAAoJEOXgvIL+s8n2yrQH/ipvFxNj4D3cu2GHw6Yfn574 bRfdRBBK/vOh1UVWsdf+fPlplYLCH8h0UZTEBh8Jy5sDkDZ238OnjbDkKAQn3rS+ xe8A/cL4Shf0h6VjSwSlPB19Pwjw3R7Z5TafuZ8oBVNBQDSGOz/itLhV3IRQUCRj QfTefTzzIs3/NxZZNB7AjNE+O4BhTqGu3CAwHwFuD7YCVpZQUga35cgscR1CkeCS TAi0RiqvVLGmywcNImfpDKkE2NKqpxHjvobMdeJ47pIlKbLl/hTznTiqPtTHixA+ oDI61HhI4GOfmvlGiGGeCryM4reByIKgyva1X06wj3rv4Sosr9vL2RtBdqjxzWc= =aYCe -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, XML Activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2015 05:36 AM, L. David Baron wrote: > The W3C is proposing revised charters for all of the working groups > in the XML Activity: > > https://lists.w3.org/Archives/Public/public-new-work/2015Jul/.html > > > http://www.w3.org/XML/2015/05/activity-proposal.html (which has a > brief summary of the work) > > recharter: Efficient XML Interchange Working Group > http://www.w3.org/XML/2015/05/exi-charter.html > > recharter: XML Query Working Group > http://www.w3.org/XML/2015/05/query-charter.html > > recharter: XML Core Working Group > http://www.w3.org/XML/2015/05/xml-core-charter.html > > recharter: XML Processing Model Working Group > http://www.w3.org/XML/2015/05/xproc-charter.html > > recharter: XSLT Working Group > http://www.w3.org/XML/2015/05/xsl-charter.html > > bring back to life: XForms Working Group > http://www.w3.org/XML/2015/05/xforms-charter.html > > > Mozilla has the opportunity to send comments or objections through > Thursday, July 30. > > Please reply to this thread if you think there's something we > should say as part of this charter review, or whether you think we > should explicitly abstain. (Note that we can only explicitly > abstain from the set of charters as a whole, not individually, at > least on the ballot form, though I suppose we could do so in > prose.) > > (My inclination is at minimum to explicitly abstain, with comments > that they shouldn't expect browser implementation.) > I'd personally prefer to shut down the entire Activity. None of these groups will help "lead the web to its full potential" (if that's still the W3C's motto). They are completely out of touch with what's happened on the Web is the last decade, exemplified by the following quote from the XML Core proposed charter: > The Working Group has current plans to: > > 1. Publish a sixth edition of XML 1.0 as an Edited Recommendation, > to include the changes for the LEIRI specification, at such time > as IRI-bis is final. This entire Activity is a distraction from the real needs of the web, and if the W3C is serious about its motto, it should focus on those rather than providing support and hosting conferences for people's petty side projects that have no bearing on the web. However, I'll already be happy if we can kill the XForms zombie. Apparently they've had a group in plh's Domain for years, and never produced anything of consequence, and now that he's finally managed to kick them out, they want to return through this back door. If the handful of people who still care about it want to continue wasting each other's time, they can always start a Community Group, or move to another standards development organization. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVrh8gAAoJEOXgvIL+s8n2OG0H/ioMX2t9p01ngpsKhmsX5yAC rNvBAf+yhkT6AanCXmXvdnvUbYXjo2zgSQmxPrhRkLWIYQHTjQN4guMoc1v5HljW JE2Aa5xT5tbKPQ2p/6smwQZyBWZxa7OwapefzrtRBXILyqOFeTG4qqgnd7Hvw1Nx N9G0e+JgiQjpvZLA3+gncLqpFwpGvQ6RIisfdFlO3QCJy6W4z2skzpLwk3oEEvuk umLYl2w6bHycn5XNEFrggZ+/q/gYzUP0hWF9+fuaHbvnPsAHAtsBPEt4tt3ocLQY Pggmb4HYF7LVmrLCo5r8iHOOWVO16iFkDa0X3YRW37AOJ3j7qLUAlKD6qnApAco= =OzSY -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Disabling tests
On 07/25/2012 02:05 AM, ben turner wrote: Peers can make the decision if it's worth disabling a test, pull someone off of other tasks to fix it, or whatever. Or in this case you claim that wasting sheriffs' time is much less important than your vacation / other tasks, as you did in the bug. Disabling test and spamming randomorange bugs are the only tools sheriffs have to force you to stop ignoring the random orange. In this case, the latter is impossible because of an issue you have been aware of for almost a month and which I have explained how to fix (a five line patch) on the first of July. I find your reaction to this situation extremely rude and disrespectful to people who put their time into keeping our tree green; a hard enough job without people insisting their unreliable tests *absolutely need* to be enabled. Thank you Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 08/16/2012 05:10 PM, Ehsan Akhgari wrote:
I think this is generally a good idea. I have a few questions before
jumping in to agree though.
1. Is the current testharness.js API the documentation at the beginning
of <http://w3c-test.org/resources/testharness.js>? If that is the case,
the API looks a lot heavier weight than the default mochitest API we
use. In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls? (I'm not 100% sure if that conversion would
be straightforward.)
I don't feel it's terribly heavyweight. In the simple case, you need a
test(function() {
// tests
});
That's two extra lines of boilerplate. Our mochitest boilerplate is…
(*looks it up*) 30 lines. I think we'll deal. The method names for
assertions (assert_*) are a bit longer than we're used to, but in my
experience, you get used to it rather quickly.
IMO, it would not be a good idea to try to layer another API on top of
this, because it makes our tests harder to understand and less reusable
by other browser vendors, and it means that experience with our brand of
testharness.js doesn't help much to understand the standard brand.
I also don't think it would be terribly straightforward, and I think
that having real mochitests, testharness.js-that-look-like-mochitest and
standard testharness.js in our tree would make our testing situation
more confusing than the lessened learning curve would be worth. In
particular, having two APIs that superficially look the same but are
actually built on unrelated frameworks seems a recipe for a lot of
annoying differences in edge cases.
2. Is there any support for running reftest-style tests in a framework
that is reusable by other browsers? If not, can we move to propose the
reftest framework to the appropriate standards bodies so that it can be
adopted by other browsers? Our reftest framework has been carefully
designed to be Gecko-agnostic, and is much superior to the equivalent
testing framework that WebKit has (not sure about other browser
engines). Furthermore, the files loaded by this framework are not
loaded in a privileged context with APIs such as SpecialPowers, which
makes a large number of them portable to other browser engines.
The W3C has already adopted reftests. See
<https://test.csswg.org/harness/test/CSS-STYLE-ATTR_DEV/single/style-attr-braces-001/>
for example.
In fact, we've already got a place in m-c to put reftests to be
submitted to the CSSWG:
<http://mxr.mozilla.org/mozilla-central/source/layout/reftests/w3c-css/submitted/README?force=1>.
The main issue here is that the CSSWG appears to impose rather stringent
test formatting requirements, which makes writing reftests for them much
more of a drag than just writing them for ourselves.
I think it makes sense for us if we can start this effort on the reftest
framework, since that has a much lower barrier to entry, and ultimately
this effort would be valuable only if other browser engines start to use
our tests (and hopefully share theirs with us as well).
Opera already shares a lot of their tests, and Google, Apple and
Microsoft have been known to submit tests as well, some of which are
already running on tinderbox.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 08/16/2012 06:21 PM, Ehsan Akhgari wrote:
On 12-08-16 11:34 AM, Ms2ger wrote:
On 08/16/2012 05:10 PM, Ehsan Akhgari wrote:
I think this is generally a good idea. I have a few questions before
jumping in to agree though.
1. Is the current testharness.js API the documentation at the beginning
of <http://w3c-test.org/resources/testharness.js>? If that is the case,
the API looks a lot heavier weight than the default mochitest API we
use. In that case, would it make sense for us to have a compatibility
layer which translates our mochitest APIs to the equivalent
testharness.js API calls? (I'm not 100% sure if that conversion would
be straightforward.)
I don't feel it's terribly heavyweight. In the simple case, you need a
test(function() {
// tests
});
That's two extra lines of boilerplate. Our mochitest boilerplate is…
(*looks it up*) 30 lines. I think we'll deal. The method names for
assertions (assert_*) are a bit longer than we're used to, but in my
experience, you get used to it rather quickly.
I was not necessarily talking about the size of the boilerblate. I was
mostly talking about the size of the API. The mochitest API is
considerably smaller than testharness.js, and is therefore easier to
read and learn, I think.
I don't really agree that the API is much larger; it's just that all the
assert_* functions are documented, unlike the various functions we
expose to mochitests.
It's of course true that this is another API to learn, but I don't think
it's significantly harder than the mochitest API for people who don't
yet know either.
IMO, it would not be a good idea to try to layer another API on top of
this, because it makes our tests harder to understand and less reusable
by other browser vendors, and it means that experience with our brand of
testharness.js doesn't help much to understand the standard brand.
I would agree if the mochitest API was also huge. We're basically
talking about 3 functions: is, is_not and ok. I don't agree that using
these functions would make our tests any less usable by other browser
vendors. But I understand that in their eyes, these functions may not
be as intuitive as in mine. :-)
How about
SimpleTest.ise()/isa()/typeOf()/isDeeply()/waitForExplicitFinish()/finish()/executeSoon()/expectUncaughtException()/…?
I would argue that functions like assert_regexp_match don't get in your
way if you don't use them, just like SimpleTest.isDeeply() never gets in
my way when writing mochitests. In general, assert_{true,false},
assert_{equals,not_equals} and maybe assert_throws are, in my
experience, sufficient for most test.
I also don't think it would be terribly straightforward, and I think
that having real mochitests, testharness.js-that-look-like-mochitest and
standard testharness.js in our tree would make our testing situation
more confusing than the lessened learning curve would be worth. In
particular, having two APIs that superficially look the same but are
actually built on unrelated frameworks seems a recipe for a lot of
annoying differences in edge cases.
Hrm, which edge cases are you talking about? Let's talk about is(a, b,
"msg") for example. Why do you think there would be cases where calling
is() is less understandable or more error prone than assert_equals?
Excellent example: is(undefined, null) passes, assert_equals(undefined,
null) fails.
However, I was thinking more about the fact that mochitest watches
window.onerror, while testharness.js catches exceptions from the
functions you pass to test(). To me, it seems easier to make sure you
use two different-looking APIs correctly, than to make sure you've got
the right API when one tries to disguise as the other.
On the testharness.js side, we have things like assert_regexp_match, for
example. I would argue that whether or not assert_regexp_match(a,
/foo/, "msg") is more readable than ok(/foo/.match(a), "msg") is very
subjective and depends on what the author of the test is used to see.
I wouldn't disagree.
HTH
Ms2ger
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 08/18/2012 12:08 AM, Gavin Sharp wrote: On Fri, Aug 17, 2012 at 5:38 PM, Justin Dolske wrote: I'm talking about the problem of having a large set of tests with a small percentage that fail intermittently, which is what we have today in m-c. What percentage of the intermittently-failing tests are tests for web features vs. tests for our UI or other Firefox-specific things, I wonder? It may be that the set of tests that would be shareable with other browsers is more reliable on average than the set of tests we have that are not relevant to other browsers. Also, the fact that a test fails intermittently in Gecko doesn't necessarily imply that it will also fail intermittently in other browsers; these failures often point to actual Gecko bugs, rather than test issues. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed policy change: reusability of tests by other browsers
On 08/24/2012 11:08 PM, Brian Smith wrote: Aryeh Gregor wrote: 1) Decide on guidelines for whether a test is internal or reusable. As a starting point, I suggest that all tests that are regular webpages that don't use any Mozilla-specific features should be candidates for reuse. Examples of internal tests would be tests written in XUL and unit tests. In particular, I think we should write tests for reuse if they cover anything that other browsers implement or might implement, even if there's currently no standard for it. Other browsers should still be able to run these tests, even if they might decide not to follow them. Also, tests that currently use prefixed web-exposed properties should still be made reusable, since the properties should eventually be unprefixed. Which other browser makers are going to follow these guidelines, so that we benefit from them? Generally, this is a great idea if it makes it faster and easier to improve Firefox. But, like Asa, I also interpreted this proposal along the lines of "Spend resources, and slow down Firefox development, to help other browsers." That seems totally in line with our values, but doesn't seem great as far as competitiveness is concerned. Looking at <http://w3c-test.org/html/tests/submission/>, there are tests from Apple, Google, Microsoft, and Opera, as well as from other organizations who benefit from interoperable implementations (Baidu, Comcast, Intel, …) and individuals (David Carlisle, Mathias Bynens, Philip Taylor, Aryeh, and myself). Some of those tests are already running on tinderbox. Also, are you saying "if you are going to write a mochitest, then try to write a reusable test" or "if you are going to write a test, write a reusable test?" The reason I ask is that we're supposed to write xpcshell tests in preference to mochitests when possible, and I'd hate the preference to change to be in favor of mochitests, because xpcshell tests are much more convenient (and faster) to write and run. Kyle already answered this. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Attribute getter naming in WebIDL bindings
On 08/29/2012 10:20 PM, Boris Zbarsky wrote: Right now, attribute getters always get prefixed with "Get" in the WebIDL bindings. So "readonly attribute long foo" becomes "int32_t GetFoo()" in the C++. Would it make sense to drop the Get in certain cases? In particular, in cases in which: 1) The getter is infallible. 2) The return value is not returned via an outparam. 3) The return value is not an interface type or is not nullable. So this IDL: readonly attribute long foo; readonly attribute Iface bar; readonly attribute Iface? baz; would become: int32_t Foo(); already_AddRefed Bar(); already_AddRefed GetBaz(); (with Iface* instead in cases when the getter is not an addreffing getter). Thoughts? It certainly looks nicer, but I'm not a big fan of complicating the rules for assembling the C++ signature from the WebIDL. XPIDL's consistency here, IMO, saves time when implementing an interface: you can focus on the actual implementation, rather than the binding code. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: try: -p all considered harmful?
On 09/29/2012 06:07 PM, L. David Baron wrote: I think the basic rule is that an individual developer ought to break Mozilla-Inbound rarely. If a developer never breaks Mozilla-Inbound, they're probably spending more extra time testing than the time they save of others interacting with Mozilla-Inbound. (And, worse, that might actually be wasting the time of many others by increasing wait times on Try.) To be honest, at this point, it feels like using Try too rarely is a bigger problem than using it too often. Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On 11/02/2012 01:47 AM, Dave Mandelin wrote: First, I want to try to pour some gasoline on the dying embers and suggest that perhaps we should totally rearrange everything. As a developer user of our testing systems, I always found it incredibly irritating that there were test directories sprinkled throughout the tree that got copied to the build dirs as part of the build process, with no clear mapping between the build path of the test, the source path of the test, and the path you had to pass to mochitests to actually run the test. This, at least, is easily solved: even today, you can run ./mach mochitest-plain foo/bar/test_baz.html and never again care about what happens in the build dir. (Yes, mach doesn't yet accept all options the python harness itself supports; patches welcome.) I would prefer something like this: |-- tests/ |-- browser-chrome/ |-- topic1 (omit this level if there would be only one) |-- topic2 |-- [...] |-- chrome/ |-- crashtests/ |-- marionette/ |-- mochitests/ |-- reftests/ |-- xpcshell |-- [..]/ This seems to suggest moving tests as far away from the code they test as possible; I don't think that's a sensible thing to do. If I'm working on, say content/html/content/src/nsHTMLInputElement.cpp, the most relevant tests are easily found in content/html/content/test/forms/. I don't see what benefit it would bring to put them further away. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
