On Fri, Nov 8, 2013 at 2:01 AM, L. David Baron dba...@dbaron.org wrote:
I think this depends on what you mean by known intermittent
failures. If a known intermittent failure is the result of any
regression that leads to a previously-passing test failing
intermittently, I'd be pretty
We are building and shipping character encoding converters that are
dead code in Firefox but that are used in Thunderbird. Considering the
Firefox binary size, it seems like a bad idea to ship to dead code in
Firefox.
Currently, this includes the encoders and decoders for UTF-7 and the
IMAP
On 11/11/2013 10:23 AM, Henri Sivonen wrote:
In principle, the right way to deal with this would be moving code to
comm-central. However, this would involve annoyances like setting up a
new XPCOM component there and making sure the category manager merges
m-c-defined and c-c-defined category
On 11/10/2013 7:54 PM, Robert O'Callahan wrote:
On Sat, Nov 9, 2013 at 7:32 PM, Benjamin Smedberg benja...@smedbergs.uswrote:
Is there a chrome-only API like .elementFromPoint that will tell me which
XBL anonymous element is at a point?
I don't think so. You probably need to add another
On 11/11/2013 17:24, Benjamin Smedberg wrote:
I'm not certain whether tbird (and seamonkey) are currently using a
shared XULRunner in Linux distros. If they are, then this approach won't
work well (we'd at least have to continue disabling these encodings via
prefs in Firefox).
I did a quick
DOM Bindings Meeting - Monday (today) @ 12:30 PM PDT
Our weeklyesque DOM bindings meetings continue on Monday Sept 30 at 12:30 PM
PDT.
time conversions:
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Meeting details:
* Monday, November 11, 2013, 12:30 PM PDT
On 11/11/2013 9:23 AM, Henri Sivonen wrote:
We are building and shipping character encoding converters that are
dead code in Firefox but that are used in Thunderbird. Considering the
Firefox binary size, it seems like a bad idea to ship to dead code in
Firefox.
Currently, this includes the
On 11/11/2013 01:33 PM, Joshua Cranmer wrote:
By far the easiest solution would be leaving the code in m-c but
#ifdefing it out of Firefox builds. Is there a compelling reason not
to do so? If there is no compelling reason against #ifdefing it out in
m-c, what's the right variable to #ifdef on
Status so far:
* The try, mozilla-inbound, b2g-inbound, and try-comm-central branches
have been running on a mixed win64-rev1 + win64-rev2 pool since October
31st.
* Project branches have been building solely on win64-rev2 since October
10th.
* Builds on the cedar and fx-team branches passed
For the sake of WebGL, GL compositing is most likely the preferred
backend for Linux/X11. Basic layers with Render compositing is
available as a fallback for those without sufficient GL support.
Our goal for X11 should be OMTC GL compositing. Adding OMTC
support for X11 basic layers will
On Mon, Nov 11, 2013 at 05:23:48PM +0200, Henri Sivonen wrote:
We are building and shipping character encoding converters that are
dead code in Firefox but that are used in Thunderbird. Considering the
Firefox binary size, it seems like a bad idea to ship to dead code in
Firefox.
Currently,
11 matches
Mail list logo
