Re: Intent to ship navigator.sendBeacon
On Wed, Apr 16, 2014 at 7:52 AM, Benjamin Smedberg benja...@smedbergs.us wrote: On 4/16/2014 9:30 AM, Richard Barnes wrote: Allows pages to send a beacon HTTP request. Beacons are allowed a limited subset of HTTP (only a few content types), and the JS cannot receive the content of the response. However, beacon requests will survive after the page is unloaded, removing the need for synchronous XHRs in onunload handlers. Are beacons primarily meant as tracking devices, or is it also meant as a way to persist unsaved page state when the user navigates? I can't imagine that there is any reasonable way to expose UI prefs specifically about beacons, but should we disable beacons by default if the user has do-not-track enabled? Or will we leave a hidden pref so that privacy-sensitive extensions could disable beacon functionality if they wished? I would expect that gathering telemetry will be at least as common as doing user tracking. But I would also expect that websites will do things like saving user state when the user leaves a page. So I don't think tying this to do-not-track would be good. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
How to use the correct fonts on Firefox OS simulators?
On Firefox OS devices, special fonts like Fira Sans and Fira Mono are used. On desktop environments (Simulator / B2G desktop), different fonts are used. We are trying to fix this in bug 992210, but we are not familiar with how fonts work in Firefox, and need some help. In Gaia, generic font names like serif, sans-serif and monospace are used instead of explicit font families for internationalization reasons. The correct font families are resolved using the localized font prefs defined in http://dxr.mozilla.org/mozilla-central/source/modules/libpref/src/init/all.js#3199, and on Firefox OS devices these fonts are installed in /system/fonts. We modified all.js to use the same localized font prefs as Firefox OS on B2G desktop environments, and this makes the simulator use the correct fonts if they are available on the system. However, on most systems the simulator runs on these fonts are not installed, so we fall back to available fonts. This is why we'd like to ship the fonts along with the simulator. We are currently thinking of packaging them inside a simulator's Gaia profile, but we're missing a way to tell Firefox where to find these fonts. How can we make the simulator use the fonts from a specific list of files we know about? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Spring cleaning: Reducing Number Footprint of HG Repos
Additionally I've been setting up a host named hg-archive.mozilla.org with a lower SLA to shelve repositories that have not been touched in many many years. Deleting this old code from hg.m.o, even if it's available elsewhere if an unpopular thing to do, so it's unsurprising I didn't receive much buy-in when I proposed it. Cool. I think the real reason for this evaluation and push into other services is that it is perceived that the user repositories don't add much value, especially when you consider all of the features that could be happening from them such as triggering CI jobs based on these, and self-service collaboration. I use them all the time to keep my personal patch queues synced across multiple machines (or even on one), and to collaborate with others on my team. I think if we advertised more how useful they are for this sort of thing it would help people work more efficiently. (And maybe tweaked the initial setup procedure just a smidge to reduce now edit this non-existant file sort of stuff.) Yes, the user-repo deletion is a feature and it is currently broken. It's been a corner-case of the migration to local disk, and a fix has yet to be coded up. Please ping me if you're trying to remove a repository until I can fix this. Add an option for delete a repo, and have it say please email bkero, for now? Thanks for the work on hg! -- Randell Jesup, Mozilla Corp remove news for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: Nightly 31 will become the next ESR
Just a friendly reminder: next week is your last opportunity to remove all those deprecated features that you don't want to support in ESR 31 until August 2015! :) https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal#Version_Numbers chris On 3/18/14, 1:40 PM, Chris Peterson wrote: So if you plan to remove any deprecated features or land major refactorings (like reformating all whitespace using using clang-format in bug 966840), Nightly 31 is a good opportunity to do so. Otherwise you will be supporting that code until ESR 31 is EOL'd in August 2015! :) If the whitespace reformatting lands in a release after Nightly 31, then every patch uplifted to ESR 31 will need whitespace fixups. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Should MutationObserver ensure HTML file nodes are run through it before they're injected in DOM?
I'm trying to use MutationObserver to do runtime localization of the nodes that are provided by an HTML file. I register the mutation observer on document at it's readyState=loading and in result all nodes that are in HTML files are reported to my callback. That's cool. Now, usually, firstPaint happen after this, so if I translate those nodes, all I see on firstPaint is a stable screen with properly translated nodes. The order seems to be: 1) observer registered 2) nodes injected into DOM 3) observer's callback translates the nodes 4) firstPaint But when I test this on a slow device (Keon) and on a rather complex app (Settings), every now and then I see a flash of untranslated content before the nodes are being translated by the mutation observer's callback. It just seems that in those cases the order is: 1) observer registered 2) nodes injected into DOM 3) firstPaint 4) obsever's callback translates the nodes Question: should mutationobserver's callback be run on those nodes before firstPaint? Or Question 2: should mutationobserver's callback be run on those nodes before they are injected into DOM? Thanks, zb. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using rr to track down intermittent test failures
The Timelapse project is cool but this thread got derailed. We have a long list of future improvements to make to rr, and improving support for JS debugging is on that list. The point of this thread is that if you're debugging intermittent test failures and you don't need much JS debugging then you should try rr if you can. People may also find that for general Gecko debugging, using rr is better than gdb alone. I generally do. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing [PID] prefix from |make mozmill| warning/error/assertion lines?
Hi, I have been analyzing warning/error/assertion lines produced by full debug version of TB (comm-central). To facilitate the analysis I created a few scripts to process the error statistically. Staring 1Q of 2014, I think such lines are prefixed with [pid] . Now that probably is very good, but unfortunately, this makes it very difficult to use a simple-minded script to gather statistical information from the log. Does anyone know how to disable this prefixing short of modifying the source code? I have found that |mach| has a command for disabling timestamp (not tested yet) --log-no-timestamp. If |make mozmill| has a similar run-time option to suppress [pid' prefix, that is great. TIA PS: the lines look as follows. Note [pid] Random sampling. [17085] WARNING: not an nsIRDFRemoteDataSource: 'remote != nullptr', file /REF-COMM-CENTRAL/comm-central/mozilla/rdf/datasource/src/nsLocalStore.cpp, line 279 [19427] WARNING: Leaking the RDF Service.: file /REF-COMM-CENTRAL/comm-central/mozilla/rdf/build/nsRDFModule.cpp, line 165 [19427] ###!!! ASSERTION: Component Manager being held past XPCOM shutdown.: 'cnt == 0', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/build/nsXPComInit.cpp, line 1020 [18458] WARNING: NS_ENSURE_TRUE(parentObject) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/accessible/src/atk/AccessibleWrap.cpp, line 1295 etc. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize
On Saturday 2014-04-19 08:36 +0900, ISHIKAWA,chiaki wrote: I see the following ASSERTION error about *800* times during test run of |mach mochitest-plain| of full debug build of FF created from M-C portion (./mozilla) of C-C source tree. They look grave but test harness seems to pass the tests themsevles most of the time. ###!!! ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 441 What does this error mean? I have not seen these assertions in full debug TB test and so not sure how grave or light the assertions are. A typical trace shows something like this (sanitized a bit to remove the timestamp at the beginning of the each line) : It probably means that there are two different classes reporting the same name to nsTraceRefcnt. Classes that use the NS_IMPL_ISUPPORTSn or NS_IMPL_ADDREF + NS_IMPL_RELEASE macros should use the fully qualified class name and not depend on being inside namespace declarations. In this case, I think the problem is mozilla::dom::MessagePort and mozilla::dom::workers::MessagePort. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize
L. David Baron wrote: Classes that use the NS_IMPL_ISUPPORTSn or NS_IMPL_ADDREF + NS_IMPL_RELEASE macros should use the fully qualified class name and not depend on being inside namespace declarations. One of our compilers complains if you try to define something in a different namespace to the one in which you declared it, so the NS_IMPL_ macros need to be in the same namespace as the class. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize
On Fri, Apr 18, 2014 at 4:56 PM, Neil n...@parkwaycc.co.uk wrote: L. David Baron wrote: Classes that use the NS_IMPL_ISUPPORTSn or NS_IMPL_ADDREF + NS_IMPL_RELEASE macros should use the fully qualified class name and not depend on being inside namespace declarations. One of our compilers complains if you try to define something in a different namespace to the one in which you declared it, so the NS_IMPL_ macros need to be in the same namespace as the class. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform I believe using declarations and top-level use of the macros works fine. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
