On 01/02/2016 14:23, Yonggang Luo wrote:
> How to remove #ifdef XP_MACOSX in xul files?
1. Move the OSX/WIN/NIX specific markup to separate XUL overlays.
2a. Ship different overlays depending on OS target.
2b. Use a chrome.manifest file with overlay directives and os specific
flags.
SeaMonkey doe
On 01/02/2016 18:17, Philipp Kewisch wrote:
> You can use runtime checks for the OS, e.g. using Services.appinfo
>
> Philipp
Dude, he's talking about XUL, not JS. Please stop giving useless advice.
Phil
--
Philip Chee ,
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from th
On Tue, Feb 2, 2016 at 11:31 AM, Chris Peterson wrote:
> On 2/1/16 3:56 PM, Mike Hommey wrote:
>> 64-bits Firefox was only officially released recently, and AFAIK, we're not
>> offering 32-bits Firefox users an upgrade to 64-bits Firefox if their
>> system permits. How about we started doing that?
On 02/02/2016 12:36, Philip Chee wrote:
On 01/02/2016 18:17, Philipp Kewisch wrote:
You can use runtime checks for the OS, e.g. using Services.appinfo
Philipp
Dude, he's talking about XUL, not JS. Please stop giving useless advice.
It's perfectly possible to runtime-change the DOM tree as n
On 2/1/2016 7:35 PM, Martin Thomson wrote:
On Tue, Feb 2, 2016 at 10:42 AM, Milan Sreckovic wrote:
Surprisingly, perhaps, there are a lot of people using Firefox on 32-bit
Windows. If I’m reading the data correctly, more than half. A small
percentage of those don’t have SSE2.
Do we have
On 02/01/2016 11:46 PM, Justin Dolske wrote:
On 2/1/16 9:51 AM, Kartikaya Gupta wrote:
Oh, I should also mention that currently many (if not all) Windows
touchscreen devices have e10s disabled by default, because a
touchscreen seems to trigger the accessibility code which disables
e10s. And if e
On 02/02/2016 12:29 AM, Kris Maglione wrote:
That falls into the category of "unless it is calling browser code and
making it do something unsafe".
That's too bad. I'm just reusing a querying function from there, and a
pretty small one.
If you need to use that function from the main proces
Hi,
To give a little insight into our work and make our work more visible to
our Community we decided to create a monthly report of what's going on in
the Sheriffs Team.
If you have questions or feedback, just let us know!
In case you don't know who the sheriffs are, or to check if there are
cu
On 1/29/2016 6:45 PM, Emma Humphries wrote:
Why This Matters
Bugs are a unit of quality we can use to see how we’re doing.
We believe that the number of outstanding, actionable bugs is the best
metric of code quality available, and that how this number changes over
time will be a strong indicat
Right, what Benjamin said - the “if I’m reading the data correctly” meant I was
looking at the telemetry results from the same link that I included in one of
the earlier replies:
http://people.mozilla.org/~danderson/moz-gfx-telemetry/www/#view=system
51.9% 32-bit Firefox on 32-bit Windows
44.7%
Here's my very lightweight counter-proposal:
Once or twice a week, automatically mail out two lists (in one email) to
the set of people Emma collected. The first are is UNCONFIRMED bugs. The
second is NEW bugs, not filed by one of the reviewers or bug admins of that
component, that haven't been to
On Tue, Feb 2, 2016 at 9:04 AM, Richard Newman wrote:
> Here's my very lightweight counter-proposal:
>
> Once or twice a week, automatically mail out two lists (in one email) to
> the set of people Emma collected. The first are is UNCONFIRMED bugs. The
> second is NEW bugs, not filed by one of th
On 2/2/16 12:04 PM, Richard Newman wrote:
Once or twice a week
Once a week is not nearly often enough.
As far as I can tell, we have effectively 4.5 weeks or so of beta before
things are locked down for ship. Lopping a week off that (or more
precisely off whatever time is left after the bug
On Tue, Feb 2, 2016 at 7:44 AM, Benjamin Smedberg
wrote:
> To keep focus and avoid creeping scope, an explicit non-goal of this
> program is to deal with the prioritization of non-critical bugs within a
> team or component. The primary goal here is to solve the flow for incoming
> bugs to a clea
On Tue, Feb 2, 2016 at 6:50 PM, Boris Zbarsky wrote:
> But it gets worse. The typical lifetime of a bug goes like this. It gets
> reported to somewhere like Firefox:Untriaged (I think we have a guided form
> that automatically dumps things there or something?). Someone goes through
> and triages
On 02/02/2016 18:04, Anne van Kesteren wrote:
On Tue, Feb 2, 2016 at 6:50 PM, Boris Zbarsky wrote:
But it gets worse. The typical lifetime of a bug goes like this. It gets
reported to somewhere like Firefox:Untriaged (I think we have a guided form
that automatically dumps things there or somet
Hello,
This was demonstrated at Mozlando by gardnt and jonasfj.
To use it:
* add --interactive to your try syntax
* wait for the task to start running
* click on "Inspect task" hyperlink
* bottom left of page when you click a job on Treeherder
* click on 'private/docker-worker/shell.html' under a
We intend to support the VP9 video codec in mp4 fragments and files.
Netflix recently proposed a specification for encapsulation of
Google's VPx family of video codecs in the ISO Base Media File Format,
more commonly known as mp4. VP9 is a royalty-free video compression
format developed by Google,
Three things more:
* This works for test jobs as well
* You can edit a task and resubmit it by adding
task.payload.features.interactive to true
* You can also click on "private/docker-worker/display.html" and get VNC
access over the browser.
* You can actually see the browser running the tests!
K
On 2/1/16 2:37 PM, Bill McCloskey wrote:
I can imagine it's frustrating if you have one of these devices, but we
have to prioritize how we spend our time. And I don't think it's worth
holding up the whole project for a few percent of users, even if they are
the cool ones :-).
Yep, incremental
On Tue, Feb 02, 2016 at 02:27:32PM -0500, Armen Zambrano G. wrote:
> Hello,
> This was demonstrated at Mozlando by gardnt and jonasfj.
>
> To use it:
> * add --interactive to your try syntax
> * wait for the task to start running
> * click on "Inspect task" hyperlink
> * bottom left of page when
On Wed, Feb 3, 2016 at 12:54 AM, Benjamin Smedberg
wrote:
>> Do we have any, say telemetry, that would move this from speculation
>> into numbers? Sure, numbers aren't necessarily perfect, but I'm sure
>> that they would help.
>
> Milan is quoting numbers from telemetry data. The last time I calc
22 matches
Mail list logo
