Web Replay
This may be a stupid question, but I just saw this on the webkit mailing list: a way to capture network/user input events (with negligible overhead) for debugging purposes. https://lists.webkit.org/pipermail/webkit-dev/2014-January/026062.html I didn't find any bugs about this; it seems interesting, though. Cheers, Dirkjan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Web Replay
On Wed, Jan 15, 2014 at 10:24 AM, Dirkjan Ochtman dirk...@ochtman.nlwrote: This may be a stupid question, but I just saw this on the webkit mailing list: a way to capture network/user input events (with negligible overhead) for debugging purposes. https://lists.webkit.org/pipermail/webkit-dev/2014-January/026062.html I didn't find any bugs about this; it seems interesting, though. There is bug 738965, which discusses a subset of this, but nobody has plans to work on it AFAIK. We even had Jake Bailey as an intern last summer who has worked on timelapse with Brian Burg, but he worked on a tracer for Firefox, not timelapse. Panos ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
TB comm-central under valgrind: Strange lock issue, and startup cache issue?
nvoking |make mozmill| TB test suite by running DEBUG BUILD of TB under valgrind has turned out to be useful in finding memory-related errors, AND timing-related thread race issues. The issues of second kind, i.e., timing issues, are not usually noticed, but often they become obvious due to the large execution time skew caused by running TB under valgrind. I found that code that ran without proper ordering (by means of mutex, etc.) suddenly causes problems under valgrind. Since refreshing my local copy of comm-central tree a couple of days ago (my previous update was around Dec 25+ last year), I have not been able to run the test suite |make mozmill| for TB (local DEBUG BUILD) under valgrind (Debian GNU/Linux, both under 32-bit and 64-bit versions). Simply put, although I lengthened the timeout value, all the tests timed out and no useful information could be obtained. This was not the case only a few weeks ago or so before the source update. I lengthened the timeout by 60 seconds, still no go. (That is, I had already set it to 330 before, and increased it this time to 390 to no avail.) I have no idea how long I should lengthen the timeout value. So I got curious and ran the locally built DEBUG BUILD TB under valgrind MANUALLY and see if anything stood out. And some DID certainly. There are a few cases of locking failure(?) in one run, and strange assertion/warning regarding startup cache. I have never seen them before. Possibly the locking failure may explain the timeout under valgrind. I wonder if anyone can shed light on these new assertions/warnings. Sorry for long posting. Below is the log printed to the tty console where TB was started under valgrind. (1) Strange locking issue? Please note the warning, PRFileDescAutoLock cannot get fd!: 'mFd', and Security network blocking I/O on Main Thread [... during startup...] JavaScript strict warning: chrome://messenger/content/tabmail.xml, line 352: reference to undefined property aTabType.panelId [30685] WARNING: PRFileDescAutoLock cannot get fd!: 'mFd', file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsSocketTransport2.h, line 195 [30685] WARNING: Security network blocking I/O on Main Thread: file /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, line 423 ++DOMWINDOW == 24 (0x1e495e68) [pid = 30685] [serial = 27] [outer = 0x1e46fb98] ++DOCSHELL 0x2b85ca60 == 12 [pid = 30685] [id = 12] ++DOMWINDOW == 25 (0x2b6eb948) [pid = 30685] [serial = 28] [outer = (nil)] ++DOMWINDOW == 26 (0x26f48768) [pid = 30685] [serial = 29] [outer = 0x2b6eb948] --DOMWINDOW == 25 (0x2b5f3188) [pid = 30685] [serial = 15] [outer = 0x1c5e3da8] [url = about:blank] [30685] WARNING: NS_ENSURE_TRUE(enabled) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/base/Navigator.cpp, line 1869 [30685] WARNING: NS_ENSURE_TRUE(enabled) failed: file /REF-COMM-CENTRAL/comm-central/mozilla/dom/base/Navigator.cpp, line 1710 [30685] WARNING: Security network blocking I/O on Main Thread: file /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, line 423 --DOMWINDOW == 24 (0x2a95a8f8) [pid = 30685] [serial = 18] [outer = (nil)] [url = about:blank] --DOCSHELL 0x2b85ca60 == 11 [pid = 30685] [id = 12] [30685] WARNING: Could not get disk status from nsIDiskSpaceWatcher: file /REF-COMM-CENTRAL/comm-central/mozilla/uriloader/prefetch/nsOfflineCacheUpdateService.cpp, line 325 ++DOCSHELL 0x1e1d4c10 == 12 [pid = 30685] [id = 13] [... eventually TB started up, and I quit it...] (1.5) Another instance of PRFileDescAutoLock cannot get fd! and blocking I/O, this time when TB checked add-on during startup. [... during start up... ] *** LOG addons.xpi-utils: Writing add-ons list [27847] WARNING: dependent window created without a parent: file /REF-COMM-CENTRAL/comm-central/mozilla/toolkit/components/startup/nsAppStartup.cpp, line 650 ++DOCSHELL 0x1dce9da0 == 1 [pid = 27847] [id = 1] ++DOMWINDOW == 1 (0x1dcefaf8) [pid = 27847] [serial = 1] [outer = (nil)] ++DOMWINDOW == 2 (0x1eb11c28) [pid = 27847] [serial = 2] [outer = 0x1dcefaf8] *** LOG DeferredSave/extensions.json: Starting timer *** LOG DeferredSave/extensions.json: Starting write Chrome file doesn't exist: /REF-OBJ-DIR/objdir-tb3/mozilla/dist/bin/chrome/toolkit/skin/classic/mozapps/update/update.png --- maybe because I am testing TB without installing it(?) [27847] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsFileStreams.cpp, line 210 [27847] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /REF-COMM-CENTRAL/comm-central/mozilla/netwerk/base/src/nsFileStreams.cpp, line 482 [27847] WARNING: Asking for app status on a principal with an unknown app id: 'mAppId != nsIScriptSecurityManager::UNKNOWN_APP_ID', file /REF-COMM-CENTRAL/comm-central/mozilla/caps/src/nsPrincipal.cpp, line 532 --- Never seen this error before! [27847] WARNING:
Non-unified builds now running periodically on all trees
Starting today [1], you'll see a new symbol on TBPL: Bn. These are builds running with unified sources disabled. We're now running these periodically on 64-bit linux (opt and debug) on all trees on the same cadence as the PGO builds. The purpose of these builds is to catch build problems that are masked by unifying the source files. By doing regular builds with unified sources disabled we'll have a smaller regression window to help pinpoint the changes which broke the non-unified configuration. Once we shake out all the issues with the linux64 non-unified builds, we'll look at enabling other platforms. Testing non-unified builds on Try is simple - just ensure your mozconfig has 'ac_add_options --disable-unified-compilation' in it. For more details, please see bug 942167 [2]. Cheers, Chris [1] Once the new tbpl code is deployed - https://bugzilla.mozilla.org/show_bug.cgi?id=960173 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=942167 signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
the good news and bad news of parallel reftests landing
The good news: bug 813742 has landed on inbound, and enables running reftests on desktop in parallel. Either: runreftest.py --run-tests-in-parallel or: mach reftest --parallel whichever you happen to use. By default, it runs #cpus * 2 + 1 jobs, so prepare for an explosion of windows. For reference, a several generations-old 8-core hyper-threaded system runs reftests in about 5.5 minutes. The bad news: this is *not* turned on by default, due to non-obvious failures in Linux IPC and Windows tests, along with a few issues on Mac. However, if you're doing development locally on Linux, this option can speed up your local testing cycle significantly. And the option makes it easier to debug the failures that prevent parallel reftests from being turned on in automation. There are a few dependent bugs from bug 813742; help fixing those or whatever other parallel-only failures your local testing turns up would be much appreciated! -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
Hi, Am 13.01.2014 01:34, Mike Hommey wrote: Let's face it: xulrunner is hardly maintained, we barely build and test it on automation, and the result is that it is often broken for long periods of time. I propose that we just stop pretending, and terminate xulrunner, considering the following: Thanks Mike for getting this topic started, even though I kind of settled very well with the status quo and was hoping sleeping dogs would not be woken up :-) But it had to happen at some point, so let's make sure we come out of this whole discussion with a better solution than we have right now. I totally agree with Mark that the lession we've learned in the past is clear: Am 14.01.2014 15:16, Mark Finkle wrote: We've know something for a long time: If Mozilla is not using a tech/project in Firefox, support for the tech/project will wither. My use case is kind of a typical XULRunner-based application. I have custom application code and distribute a private (self-build, unpatched but localized) XULRunner copy with it. It runs on Windows and Linux. I don't see any problems with using a custom copy of Firefox instead of XULRunner for my use case at first sight. - Since bug 755724, running firefox -app application.ini is 99% the same as running xulrunner application.ini, except for a few details that should be considered bugs. Before that bug, it was quite different, as browser-specific files were available to the xul application. sounds good, even though I don't get the whole story in bug 755724, the discussion there is rather extensive :-) - There is no reason we can't generate the sdk from firefox instead of xulrunner. Moreover that would make firefox-specific interfaces available in the sdk that aren't currently (which may or may not be a good thing, arguably) If the application doesn't need to use it I don't see any problem with it. - We could include the xulrunner and xulrunner-stub executables as part of firefox. xulrunner-stub is small and self-contained, and xulrunner could be replaced by something that calls firefox -app. Or we could make the firefox executable check under what name it's called and act accordingly. The functionality of xulrunner-stub is really nice and I'd be glad if it could be retained. To me making Firefox check under which name it was called and act then like xulrunner-stub sounds like the solution which has the largest chance of staying supported. I'm volunteering to help out with patches here if it is clear which way we want to go. The simplest solution probably would be to just keep the xulrunner-stub code as it is somewhere, maybe behind a ./configure option, for those people who need it. Another thing that kind of comes together with xulrunner-stub is the redit.exe tool (in xulrunner/tools/redit) to replace the icon of an EXE file. Again, it would be nice if it could stay in the tree somewhere, but otherwise I'd just take it to some github repo and be fine with it. Since it seems that all other parts that I need are there already I'll give this whole thing a try next week and report back how things go. An open question right now would be how the updater will handle things. As a closing remark, since this discussion is not prompted by any immediate problem with XULRunner from what I understand, I'd be happy if things could stay the way they are until we come up with some alternatives or decide that a particular problem will have no alternative solution. Just don't rip out the code as first step :-) Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
Am 15.01.2014 23:08, Marcio Galli wrote: Something to check, that resides between engineering and legal, is how easy it will be for a third-party to ship the Firefox code (with the --app). While I understand that no UI is to be shown, I believe that we need to check legal aspects regarding the use of Firefox code - it's restrictions and consequences, let s say to bump a case - think of a bug in Gecko or something else that would lift behavior from Firefox bits and pieces with trademarks. My understanding (and I'm not a Mozilla lawyer or anything, so it would be good for someone from the legal team to give final answers here): - Distributing an unmodified, official Firefox build should not be a problem, even if you use it just to start another application using the --app switch). - Building a custom, possibly modified version of Firefox as XULRunner replacement and distributing that should not be a problem if built with the unofficial branding (the default), since this branding should not contain any trademarks. Philipp ___ 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
Count me as another person in favor of an 80-column hard limit because of being able to open two files side-by-side with that limit, but not anything wider (even 100 is too wide). I spend a lot of time with an editor window tiled against a whole bunch of MXR tabs. I either don't care or can live with everything else under discussion. (If there were a chance of getting rid of the useless scoping prefixes on *everything*, as a big bang rewrite-the-entire-tree change, I would be for it. But somehow I don't think that's going to happen.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS
On 2014-01-06 7:58 PM, Karl Tomlinson wrote: smaug sm...@welho.com writes: Why this deprecation? NS_ENSURE_ macros hid return paths. That was exactly why they were a Good Thing! Normal control flow was emphasized. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote: On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't see any valid argument that backs up the decision to not fix the issue. At least none that would stand to the objection which I posted as a comment: Having a standard message always displayed is ok, but what's the reasoning behind not allowing to _add_ a custom text?!?!?!? [Note to list: I think this is an honest question which deserves a straight answer, and although I suspect the answer I'm about to give is somewhere in Bugzilla, I can't blame the poster for overlooking it in a giant bug thread full of shouting.] I am not the person who made this decision, but I agree with it, and this is why. If we allow the page to customize the onbeforeunload confirmation box _at all_, a malicious page can - just with clever wording - confuse the user into misunderstanding the standard message. The standard message we have right now is pretty hard to misunderstand, but we have actually seen things like IF YOU PRESS LEAVE PAGE YOUR COMPUTER WILL CRASHone! in the wild, and we have support tickets saying people were actually scared by that sort of thing. It's also conceivable that a malicious page could use Unicode trickery to render the standard message unreadable; we *might* be able to prevent that, but we would never be sure we had gotten every single way. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Support for non-UTF-8 platform charset
On 2013-11-26 5:40 AM, Neil wrote: Henri Sivonen wrote: On Windows, do we really need to pay homage to the pre-NT legacy when doing Save As? How about we just use UTF-8 for HTML Page, complete reserialization like on Mac? You'll need a BOM, of course. (MXR turns up so little that it makes me wonder non-UTF-8 support might have already gone away for practical purposes.) Gecko gets a little confused when you run Linux on a non-UTF8 file system, so I'd agree with this. FWIW some time later, I've seen both Linux and *BSD devs state that even if the user's locale uses a legacy encoding, all filesystem paths should still be treated as UTF-8. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On closing old bugs
On 2013-11-27 2:36 AM, Gabriele Svelto wrote: While looking through bugzilla I often stumble in my searches on old bugs - sometimes very old - which after a quick look I realize have either already been fixed or won't be (because they pertain to some old, unsupported platform for example). Much of what I would have said here has been said by other people, so I just want to add that going through old bugs, one by one, and determining whether they are still relevant *is* tremendously valuable, and you should not feel discouraged from doing it. But it is important that you actually check each one. (When I've done this, more than half of the bugs *had* already been fixed or overtaken by events, and a fair number of the remaining ones did not have sufficient information to reproduce the problem, but about 25% were still live bugs.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
