On 16/08/2012 4:10 PM, Mike Hommey wrote:
...
Something I noticed recently is that we spend more than 5 minutes (!)
during windows clobber builds to do the clobber (rm -rf). All try builds
are clobbers.
IME, rd /s/q is usually much faster than rm -rf - using cmd /c rd
/s/q obj-xxx might be
On 7/05/2013 11:49 PM, Mike de Boer wrote:
TLDR; in bug 867742 I requested to adopt two JS modules, Async.jsm
and AsyncTest.jsm, in mozilla-central/toolkit/modules. The whole
story can be read below as well as at
https://gist.github.com/mikedeboer/5495405. I posted about this
subject before on
On 27/06/2013 5:15 PM, Gervase Markham wrote:
On 26/06/13 08:45, Mark Hammond wrote:
There is evidence users find this troubling - eg, bug 762610 reports
that a couple of users wrote to the mozilla webmaster about this. While
it may just be a perception, it seems a perception worth managing
On 25/06/2013 5:29 PM, Gervase Markham wrote:
On 17/06/13 21:48, Drew Willcoxon wrote:
Toolkit already has a thumbnail module, [PageThumbs], but it can only
capture thumbnails of open content windows, same as they appear to
the user. Windows may contain sensitive data that should not be
As a bit of background, I'm working on an enhancement to our Social
API. We currently have the concept of a FrameWorker, which is
basically a simulation of a SharedWorker implemented by hosting an
iframe in the hiddenDOMWindow. This iframe loads content from a (real)
site, and needs access to
Felipe and I were having a discussion around a patch that uses
nsIMessageManager. Specifically, we create a browser element, then
call browser.messageManager.addMessageListener() with the requirement
that the listener live for as long as the browser element itself.
The question we had was
.bugzilla.mozilla.org/attachment.cgi?id=774978
On Thu, Jul 25, 2013 at 6:51 PM, Mark Hammond mhamm...@skippinet.com.au wrote:
Felipe and I were having a discussion around a patch that uses
nsIMessageManager. Specifically, we create a browser element, then call
browser.messageManager.addMessageListener
On 3/08/2013 5:30 AM, Philip Chee wrote:
On 02/08/2013 16:57, t...@adblockplus.org wrote:
The code in question was explicitly running in Firefox Mobile only.
It used messageManager.loadFrameScript() API to inject code into the
content process of new tabs - I doubt that it will work the same
On 6/08/2013 2:30 AM, Robert Kaiser wrote:
We also get worse thumbnails than before on pages that are basically
just a big login screen when you aren't actually logged in.
In the short-term, bug 897880 might help with that - it will arrange so
that an error response (roughly, a non 2XX
On 21/08/2013 5:36 AM, Gregory Szorc wrote:
...
Finally, this is just a friendly reminder that if you build
mozilla-central and you don't have a machine with at least 4 *physical*
cores, 16 GB RAM, and an SSD, you should upgrade your hardware.
FTR, my Windows machine has 16GB of ram, 4
On 28/08/2013 3:30 AM, Gregory Szorc wrote:
...
Does anyone else see this libraries-always-rebuild behavior?
Not me - although I see just a few small ones - relevant parts of the log:
5:20.54 webapprt.obj
5:21.01 webapprt.cpp
5:21.01
5:21.05 webapprt-stub.exe
5:21.07 MakeNSIS
On 18/09/2013 8:06 AM, Tim Abraldes wrote:
This is a re-post from firefox-dev [3], in case anyone in
dev-platform is aware of historical context. Please follow-up here
in dev.platform (I think it's easier for users/mail-clients to jump
into a newsgroup discussion than a mailing list discussion)
On 20/09/2013 5:36 AM, Tim Abraldes wrote:
Separating and summarizing a little, it sounds like:
For alert/prompt/confirm, we're all (mostly?) agreed that the
prevent this page from creating additional dialogs checkbox should
have its meaning changed from rate limit future
alert/prompt/confirm
On 23/09/2013 2:46 PM, Gregory Szorc wrote:
On Sep 22, 2013, at 18:20, Mark Hammond mhamm...@skippinet.com.au
wrote:
On 23/09/2013 11:04 AM, Gregory Szorc wrote:
On Sep 22, 2013, at 16:35, Anthony Jones ajo...@mozilla.com
wrote:
On 21/09/13 17:58, Robert O'Callahan wrote:
I don't think
On 22/10/2013 2:57 AM, Matthew Gertner wrote:
On Monday, October 21, 2013 5:45:44 PM UTC+2, Neil wrote:
Well, you could turn of that error; it's just a pref. Of course you
would then decide whether to trap all the other DOMWindowClosing events
to stop other random scripts from closing windows.
On 31/10/2014 11:45 AM, Chris Hofmann wrote:
The place we really need this is b2g, but phones are only shipping in
international markets right now so english only is not all that helpful.
While this doesn't change the point you are making in any way, FWIW,
Firefox OS phones are on sale in
In bug 1100069, bz suggested I look at using Components.returnCode so a
JS component called by c++ can return failure without having an
exception logged.
However, this isn't working as I expect. Further, the few uses of this
in the tree also don't seem to work as expected.
SessionStore.js
On 24/11/2014 8:40 PM, Philipp Kewisch wrote:
On 11/24/14 1:43 AM, Mark Hammond wrote:
* Is Components.returnCode expected to be used when the code throws (as
SessionStore.jsm does) or when the code returns without an exception?
(Or maybe both?)
* If it is supposed to be used with a normal
On 9/12/2014 7:52 AM, Gijs Kruitbosch wrote:
Because I've been working on a few of them and here's what I think would
make them a lot easier to fix, and therefore improve our test coverage
and make sheriffs much happier
When I look at oranges, I typically push some diagnostics to try and
Just an hour or so ago, support landed on mozilla-central which gives us
the ability to use the devtools debugger to debug xpcshell tests \o/
To use this, simply add --jsdebugger to the xpcshell/mach command-line
- eg:
./mach xpcshell-test --jsdebugger path/to/a/test.js
then wait for the
On 11/02/2016 11:38 AM, Valentin Gosu wrote:
TL;DR - Firefox does pretty well when compared to Chrome.
The Presto project is a Mozilla platform initiative that intends to look
into any performance differences between Firefox and other UserAgents in
order to highlight areas that we should look
On 22/01/2016 6:12 PM, Gregory Szorc wrote:
Code review will continue to shift from Bugzilla centric to MozReview
centric. And this means that Bugzilla flags mean less and less over
time. Perhaps we can solve intent in MozReview without having to change
anything in Bugzilla...
(Hopefully)
Given our recent performance push, I thought I'd bring this topic up again.
When writing loops using async functions in browser code, it's still
very easy to cause jank. For example, a trivial function:
> async function janky() {
> for (let i = 0; i < 10; i++) {
> await
On 5/18/17 12:03 PM, Boris Zbarsky wrote:
On 5/17/17 9:22 PM, Mark Hammond wrote:
I'm wondering if there are any ideas about how to solve this optimally?
I assume
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method doesn't
have quite the right semantics here
On 5/18/17 12:03 PM, Boris Zbarsky wrote:
On 5/17/17 9:22 PM, Mark Hammond wrote:
I'm wondering if there are any ideas about how to solve this optimally?
I assume
https://w3c.github.io/requestidlecallback/#the-requestidlecallback-method doesn't
have quite the right semantics here
On 5/19/17 8:00 PM, Andreas Farre wrote:
So if you have a look at how the idle callback algorithm is defined[1]
and what timeRemaining is supposed to return[2] you see that
timeRemaining doesn't update its sense of idleness, it only concerns
itself with the deadline. So if you save the
26 matches
Mail list logo
