Re: Reordering opened windows
David Rajchenbach-Teller wrote: We are considering redesigning slightly how windows are reopened by Session Restore, to ensure that most recently used windows are loaded first. I can't quite tell from your phrasing whether the bottleneck here is the time it takes to open windows. I'm assuming it is, and that Session Restore has to wait for all the windows to open so that it can prioritise loading the most recent window first. Since Session Restore already knows things such as the size and position of the window it wants to restore, I'm wondering whether it might it be possible to open the windows to about:blank and then start loading browser.xul in the most recent window first. (Obviously this only helps if there are three or more windows to restore, since you have to have loaded browser.xul in the first window to know you want to restore the previous session.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reordering opened windows
It seems like the solution to this would be for the first opened window to trigger the session restore, and the session restore process goes like this: 1. Open additional win32 windows in the correct order 2. Load the basic browser XUL into each window 3. Bring the 'priority load'/active window to the foreground (*not* reorder it, just focus it) - iirc on Win32 this will work if Firefox is currently focused, and if it's not focused it will not work but the user won't notice. 4. Load tabs into the priority load window until you're done. 5. Load tabs into the non-priority load windows. That seems like it would ensure that the active window (the one the user is most likely to want to browse with, and the one that will be focused) loads and becomes responsive first while the other windows load in the background. On Sun, Jul 6, 2014 at 2:08 AM, Neil n...@parkwaycc.co.uk wrote: David Rajchenbach-Teller wrote: We are considering redesigning slightly how windows are reopened by Session Restore, to ensure that most recently used windows are loaded first. I can't quite tell from your phrasing whether the bottleneck here is the time it takes to open windows. I'm assuming it is, and that Session Restore has to wait for all the windows to open so that it can prioritise loading the most recent window first. Since Session Restore already knows things such as the size and position of the window it wants to restore, I'm wondering whether it might it be possible to open the windows to about:blank and then start loading browser.xul in the most recent window first. (Obviously this only helps if there are three or more windows to restore, since you have to have loaded browser.xul in the first window to know you want to restore the previous session.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Interfaces nsIX509Cert2/nsIX509Cert3 and nsIX509CertDB2 merged with nsIX509Cert/nsIX509CertDB respectively.
Hi All, Interfaces nsIX509Cert2, and nsIX509Cert3 have been merged with nsIX509Cert. Similarly, nsIX509CertDB2 has been merged with nsIX509CertDB. Hence, these are the only two ( nsIX509Cert and nsIX509CertDB) which should be used going forward. All required functions can only be accessed through these. Small changes to existing add-ons which use these interfaces will be required once the patch lands. This has been done as there is no reason for these to be separate, since we don't freeze interfaces. Bug has been marked as dev-doc-needed and addon-compat. Bug : https://bugzilla.mozilla.org/show_bug.cgi?id=643041 Harsh ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Depending on libnotify
Philip Chee writes: On 02/07/2014 18:13, David Rajchenbach-Teller wrote: We had libnotify support but this was removed from the tree on the grounds that it didn't suit our needs. I don't think those were the grounds. AIUI it was just that people didn't want to put effort into a lower priority platform, so it was easier to remove existing support. But libnotify provides something quite different from the layer on inotify that David wants here. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Try-based code coverage results
I don't know how many people follow code-coverage updates in general, but I've produced relatively up-to-date code coverage results based on http://hg.mozilla.org/mozilla-central/rev/81691a55e60f, and they may be found here: http://www.tjhsst.edu/~jcranmer/m-ccov/. In contrast to earlier versions of my work, you can actually explore the coverage as delineated by specific tests, as identified by their TBPL identifier. Christian's persistent requests for me to limit the depth of the treemap view are still unresolved, because, well, at 2 AM in the morning, I just wanted to push a version that worked. The test data was generated by pushing modified configs to try and using blobber features to grab the resulting coverage data. Only Linux32/64 is used, and only opt builds are represented (it's a --disable-optimize --disable-debug kind of build), the latter because I wanted to push a version out tonight and the debug .gcda tarballs are taking way too long to finish downloading. Effectively, only xpcshell tests, and the M, M-e10s, and R groups are represented in the output data. M-e10s is slightly borked: only M-e10s(1) [I think] is shown, because, well, treeherder didn't distinguish between the five of them. A similar problem with the debug M(dt1/dt2/dt3) test suites will arise when I incorporate that data. C++ unit tests are not present because blobber doesn't run on C++ unit tests for some reason, and Jit-tests, jetpack tests, and Marionette tests await me hooking in the upload scripts to those testsuites (and Jit-tests would suffer a similar numbering problems). The individual testsuites within M-oth may be mislabeled because I can't sort names properly. There's a final, separate issue with treeherder not recording the blobber upload artifacts for a few of the runs (e.g., Linux32 opt X), even though it finished without errors and tbpl records those artifacts. So coverage data is missing for the affected run. It's also worth noting that a few test runs are mired with timeouts and excessive failures, the worst culprit being Linux32 debug where half the testsuites either had some failures or buildbot timeouts (and no data at all). If you want the underlying raw data (the .info files I prepare from every individual run's info), I can provide that on request, but the data is rather large (~2.5G uncompressed). In short: * I have up-to-date code-coverage on Linux 32-bit and Linux 64-bit. Opt is up right now; debug will be uploaded hopefully within 24 hours. * Per-test [TBPL run] level of detail is visible. * Treeherder seems to be having a bit of an ontology issue... -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
