-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
To build Firefox with support for process sandboxing, you currently
pass the "--enable-content-sandbox" flag. On Windows, using the
"--enable-content-sandbox" flag causes an extra DLL to be built -
sandboxbroker.dll - which is responsible for providing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Build took 41:02 with these options:
ac_add_options --enable-chrome-format=flat
ac_add_options --disable-optimize
ac_add_options --enable-debug-symbols
ac_add_options --disable-crashreporter
ac_add_options --disable-updates
ac_add_options -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The chromium IPC code is ours now, so we can mdify it as needed.
> Not sure about the Chromium sandbox code.
The Chromium sandbox code lives at "security/sanbox" in the tree.
AIUI, we wanted to be able to pull upstream changes easily so we've
avoide
> >> Possible compromise: have this info live in the tree as part of the
> >> in-tree docs under build/docs. You need build peer review to update
> >> those docs and they are versioned with the tree. That addresses my
> >> accuracy and versioning concerns.
> >
> > This sounds reasonable to me! The
> I would favour a whiteboard tag or keyword on the bug tracking the build
> failure. It should be easy enough to create a query for all open bugs
> with this tag. Usually you want to get to the bug anyway for the latest
> workaround and/or info on what to back out locally.
I'm not opposed to a wh
> >>> 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 l
> > 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 fai
> I like where you are coming from.
Yay!
> However, if we know what build bustage is known, it should be codified
> in the tree and the build should abort or you should see a giant
> warning. If we put this information anywhere else, I fear it will become
> out of date very quickly or filled with
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 hope this change makes you happy!
It most certainly does! I'm a huge proponent of code cleanup and organization,
and this looks like a beautiful example of those.
> Finally, the root class, WidgetEvent, has As*Event class. The "*"
> doesn't include the prefix. I.e., for WidgetMouseEvent, th
I wrote a reply which I then accidentally sent only to Mark. In any case, we
chatted in #developers about this.
I'm going to do the following:
1. Update the patch in bug 856977 (dialogs shouldn't be possible during
beforeunload) so that it doesn't affect the behavior of the checkbox
2. Put t
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" to "prevent future
alert/prompt/confirm.
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)
The test page at [1] illustrates the curre
> > Sadly, mercurial doesn't support having multiple working directories
> > from a single clone, which would be useful to avoid wasting so much
> > disk space on .hg.
>
> I'm 85% sure that Mercurial, on filesystems that support it, creates
> hardlinks instead of copies if you hg clone mozilla-cen
In this thread [1], we discussed a proposal that aimed to clean up
Windows widget code, speed up performance, and consolidate desktop and
metro logic. Thanks to everyone who participated in that thread! Based
on the input there, and an extensive discussion in #windev, the
following seems to be wha
>> The metro/WinRT widget backend can take advantage of native gesture
>> recognition, so maybe in the future we would want to implement the
>> ability to opt-out of front-end gesture recognition. I don't think we
>> should do this in the immediate term, but as backends get better and
>> better nat
> 1) abandon generating nsIDOMSimpleGestureEvents on Windows for both
backends
> when processing touch input from touch input displays.*
>
> This would mean that if the desktop front end wants to do something with
> pinch or zoom, it would have to process W3C touch events instead. Note
that
> we co
17 matches
Mail list logo
