> but tart will regress by ~20%, and several other suites will regress as well.
> We've investigated this extensively and we believe the majority of these
> regressions are due to the nature of OMTC and the fact that we have to do
> more work.
Where can I read more about the TART investigations? I
On Sun, May 18, 2014 at 11:48 AM, wrote:
> Re TART regressions and Gavin's concerns - as always, we should
> not trust the numbers blindly.
>
> The first thing we need is probably taking few windows machines with
> different performance characteristics and compare tab animation perf
> on those ma
I think it might help your case to acknowledge the often significant
difference between "technically possible, but expensive and
unreliable" and "extremely simple and 100% reliable". That something
is already technically possible does not mean that making it easier
has no consequences. Arguing that
On Tue, May 20, 2014 at 10:46 AM, Eli Grey wrote:
> Gavin: The fingerprinting entropy exposed by Rik's patch is actual
> *magnitudes* less than the entropy exposed on
> http://renderingpipeline.com/webgl-extension-viewer/
>
I didn't claim otherwise - personally I don't think the fingerprinting
ar
gt; does suggest to me that we need to take another look at the tests now.
>
> - Vlad
>
> - Original Message -
> > From: "Gijs Kruitbosch"
> > To: "Bas Schouten" , "Gavin Sharp" <
> ga...@gavinsharp.com>
> > Cc: de
Do either of you have reasoning for that other than "it looks better
to me"? I personally think consistency trumps any personal preferences
based on length/concision, as long as what we end up with isn't
unreasonably long/verbose.
Gavin
On Mon, Jun 2, 2014 at 4:47 PM, Ehsan Akhgari wrote:
> On M
On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky wrote:
> I think what xpcshell has now and what testharness says and what's being
> proposed (with the "Assert." prefix) are unreasonably long/verbose.
I suspected this is where we'd end up :) "Reasonability" is just as
subjective as aesthetics.
I re
Jun 3, 2014 at 1:56 PM, Ehsan Akhgari
wrote:
> On 2014-06-03, 1:49 PM, Gavin Sharp wrote:
>
>> On Mon, Jun 2, 2014 at 9:35 PM, Boris Zbarsky wrote:
>>
>>> I think what xpcshell has now and what testharness says and what's being
>>> proposed (with the &
I still don't believe either of you :) Obviously my position isn't
"let's make it it more frustrating to write tests"; I think you're
both vastly overstating the costs of switching to a slightly
different, similar API. Any change is initially jarring, but I just
don't buy that this change would cau
On Thu, Jun 5, 2014 at 3:33 AM, Mike de Boer wrote:
> I want that to happen, which is most ‘cost-efficient’; if that’s moving the
> implementation of `is`, `isnot`, `ise` to a separate module whilst keeping
> the method names available to all Mochitest(-browser) tests, than we do that.
>
> If pr
On Sun, Jun 1, 2014 at 2:11 PM, Chris Pearce wrote:
> I think we should have the UX discussion ASAP, so that we can get on with
> implementing it ASAP.
>
> I don't know where we'll be having that discussion, I don't know how the UX
> people and their process works.
For Firefox desktop UX discussi
On Mon, Jun 30, 2014 at 12:24 AM, Masayuki Nakano wrote:
> One is not in UI but shown in the list of about:config. The other is not in
> both UI and about:config. I.g., there is a checking the pref value code but
> not included in all.js and other similar files.
>
> I think that the former is impo
On Fri, Jun 20, 2014 at 7:25 AM, Benjamin Smedberg
wrote:
> I believe that we should not be adding hidden prefs just because a small
> minority of people might want a feature, but we've decided not to expose it
> in the browser preferences. Those kinds of choices should be made by
> installing Fir
Which warning are you referring to exactly? Do you have a screenshot?
Gavin
On Fri, Jul 18, 2014 at 5:48 AM, JW Clements wrote:
> The issue was resolved by Oracle some time ago.
> Continued display of this message is disconcerting to some people and
> unwarranted.
> It was a good thing when the
I added the following filters to my account:
Any Any Iteration Any Exclude
Any Any Points Any Exclude
My expected behavior is:
- if someone modifies the Points field -> bugmail filtered
- if someone modifies the Points field and the Iteration field ->
bugmail filtered
- if someone modifies the Po
the "blocked" message
unnecessarily?
With click to play on by default we could probably remove the broad
block, but we'd want to still block the known-vulnerable versions,
which would require coming up with a regexp that matches only the
right versions.
Gavin
On Fri, Jul 18, 2014 at
Does it appear in about:addons for the affected profile, under "Experiments"?
What is the value of the experiments.manifest.uri pref in that profile?
Gavin
On Thu, Jul 31, 2014 at 9:59 AM, Martin Thomson wrote:
> On 31/07/14 09:55, Mike Conley wrote:
>>
>> Can you show us a screenshot of this b
I commented in your bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=1047117) - looks like an
add-on installed by Test Pilot.
Gavin
On Thu, Jul 31, 2014 at 3:38 PM, Martin Thomson wrote:
> On 31/07/14 15:31, Gavin Sharp wrote:
>>
>> Does it appear inabout:addons for the a
This is certainly a big one, but
https://bugzilla.mozilla.org/showdependencytree.cgi?id=833098&maxdepth=1&hide_resolved=1
suggests we will still need to worry about mimeTypes.rdf and
install.rdf/update.rdf, unfortunately...
Gavin
On Mon, Aug 4, 2014 at 12:55 PM, Benjamin Smedberg
wrote:
>
> On 7
What does that alias point to? Seems to me a public mailman mailing
list would be a better choice, since then people can
subscribe/unsubscribe on their own.
Gavin
On Tue, Aug 12, 2014 at 7:57 AM, wrote:
> From now on all alerts will be sent by default also to
> telemetry-ale...@mozilla.com.
>
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari wrote:
>> In this context, an app that performs in-place updates, as opposed to full
>> page reloads, when transitioning between different views. The views can
>> use
>> different JS, CSS, and so on. To achieve this, you have to build your app
>> in a
You should use ./mach mochitest-* to run mochitests.
Gavin
On Mon, Aug 18, 2014 at 4:45 PM, Neil wrote:
> Time was that you could just python runtests.py to run mochitests.
>
> Then we needed modules that you don't get in the default python, so you had
> to invoke python from the virtualenv inst
> Going with our test disabling policy
> (https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy), I am going to
> get ready and disable tests on Friday.
A few issues here:
- This particular case (we're making broad changes to how the tests
run that causes many new failures) was not what that
Tue, Aug 19, 2014 at 9:00 AM, jmaher wrote:
> On Tuesday, August 19, 2014 11:46:08 AM UTC-4, Gavin Sharp wrote:
>> > Going with our test disabling policy
>> > (https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy), I am going to
>> > get ready and disable t
On Tue, Aug 19, 2014 at 9:06 AM, Ed Morley wrote:
> Agreed that this case is possibly slightly different - however this change
> is merely exposing already flaky tests - and this change is very much
> overdue. If the tests mentioned are really that important, then could we
> please get people allo
e tests until there is time to fix the issues.
>
> Thanks again for all the work so far on this.
>
> -jmaher
>
>
>
> On Tue, Aug 19, 2014 at 3:08 PM, Gavin Sharp wrote:
>
>> On Tue, Aug 19, 2014 at 9:06 AM, Ed Morley wrote:
>> > Agreed that this case is poss
I spoke to Mark Hammond about this yesterday. Mark has done some work
getting the browser-chrome tests running (bug 932142), but that work
was put aside for the FxA-Sync-in-29 push earlier this year. We have a
work week next week, we'll try to figure out how he can best help
broaden test coverage f
Improved password management is one of the top-line initiatives that
we're currently discussing as a focus for Firefox in 2015, so you'll
probably hear more about it soon.
Gavin
On Tue, Oct 21, 2014 at 9:03 PM, Chris Peterson wrote:
> On 10/21/14 8:28 PM, Doug Turner wrote:
>>
>> And, I think we
just not possible.
Gavin
On Wed, Oct 29, 2014 at 3:38 PM, Drew DeVault wrote:
> I was mistaken - for some reason I thought it was not fixed. Still,
> though, it's a good example for the problems with bugzilla, and the
> topic as a whole is still worth discussing.
>
> (cc: de
> https://bugzilla.mozilla.org/show_bug.cgi?id=1072980
>
> was filed 6 weeks ago, and diagnosed as relating to force rtl (but Firefox's
> fault, because we're passing CPOWs to functions that should never have them)
> within a few days, after which nothing happened.
ForceRTL is not a commonly insta
> If we have enabled e10s for nightly, are the normal non-e10s-test jobs going
> to run with the pref off?
Yes.
Gavin
On Fri, Nov 7, 2014 at 9:24 AM, Armen Zambrano wrote:
> If we have enabled e10s for nightly, are the normal non-e10s-test jobs going
> to run with the pref off?
> If not, we wou
Yes, it is currently disabled by safe mode.
There is currently a checkbox in prefs to toggle it, in Nightly
builds. When it rides the trains, we'll have to re-evaluate that
tradeoff at various steps based on the quality level and testing
goals. In the long term it does not make sense to maintain t
What downsides do you see?
Gavin
On Tue, Jan 6, 2015 at 5:43 PM, Jet Villegas wrote:
> The current Firefox implementation via a context-menu item (presumably
> available to screen readers) seems innocuous to me. While I agree with many
> of the points objecting to the spec, I don't see much upsi
+firefox-dev (more relevant to that list than dev-platform, IMO)
I would certainly support an audit of what we're migrating, I bet a
lot could be cleaned up.
Gavin
On Tue, Jan 20, 2015 at 2:40 PM, Justin Dolske wrote:
> On 1/19/15 4:58 AM, Henri Sivonen wrote:
>
>> I think this leads to a more
What does it mean to "save your for later viewing"?
I don't think there's a lot of overlap between sites that would use
the functionality roc is proposing, and sites that make sense to "save
for later viewing".
Gavin
On Mon, Feb 23, 2015 at 10:36 AM, Jonas Sicking wrote:
> On Sun, Feb 22, 2015
On Mon, Feb 23, 2015 at 11:56 AM, Jonas Sicking wrote:
> On Mon, Feb 23, 2015 at 10:56 AM, Gavin Sharp
> wrote:
> > What does it mean to "save your for later viewing"?
>
> In gmail it would mean saving the set of emails that you are currently
> looking at.
>
For popup blocking and notifications, I agree with Andreas - the
tradeoff from the user perspective is not right.
Gavin
On Fri, Mar 6, 2015 at 10:23 AM, wrote:
>
>> On Mar 6, 2015, at 6:18 PM, Ehsan Akhgari wrote:
>>
>> On 2015-03-06 1:14 PM, andreas@gmail.com wrote:
>>>
On Mar 6, 201
> Is there any place in the UI to improve this via messaging? For example,
> https://site.com/ => "Would you like to share your camera with site.com?",
> but http://site.com/ => "Would you like to permanently share your camera
> with any site claiming to be site.com? *Note: Firefox cannot verify th
This is a difficult problem to discuss in the abstract.
It should never be the case that you are "waiting for weeks/months" -
you should either be getting reviews within a week (at worst), or be
getting responses saying "can't spend time reviewing this now". Where
that is not happening, the escala
re lacking in reviewers, and let's get some peers/reviewers
added to those lists. I'm happy to help.
Gavin
On Thu, Mar 19, 2015 at 3:46 AM, Gabor Krizsanits
wrote:
> On Wed, Mar 18, 2015 at 4:47 PM, Gavin Sharp wrote:
>
>> This is a difficult problem to discuss in the abst
Redirecting this to firefox-dev, which is more appropriate.
Gavin
On Fri, Apr 3, 2015 at 9:33 AM, Philip Chee wrote:
> Let's take for instance:
> Bug 1150006 - Get rid of "-aero" file name suffixes, part 4: replace
> some Windows icons with Gtk stock icons on Linux.
>
> Once upon a time on Linux
> We don't have telemetry yet. I've done some measurements and haven't found
> any cases where tab switching consistently takes longer in e10s. However,
> it's certainly possible that it does on average. Either way, it's hard to
> investigate until we can reproduce the problem.
I see the spinner f
I think you can get this fairly easily by just changing one of the
values (Vendor or Name) in build/application.ini such that a different
profile folder is used.
Gavin
On Wed, Apr 8, 2015 at 12:28 PM, L. David Baron wrote:
> On Wednesday 2015-04-08 12:08 -0700, Seth Fowler wrote:
>> I think one
I think that's overthinking it - I doubt Seth was intending to distribute these
builds widely or frequently. A few leftover profile files won't hurt anyone :)
Gavin
> On Apr 8, 2015, at 1:48 PM, Xidorn Quan wrote:
>
>> On Thu, Apr 9, 2015 at 7:49 AM, Gavin Sharp wro
> How many of these can you correctly predict the result of?
Knowing Gijs, I know the answer is "all of them" :)
This is certainly a factor in this discussion - how familiar you are
with JS, and how much you use it every day, certainly affects your
perspective. Gijs' (and my) experience is that u
On Fri, Aug 17, 2012 at 5:38 PM, Justin Dolske wrote:
> I'm talking about the problem of having a large set of tests with a small
> percentage that fail intermittently, which is what we have today in m-c.
What percentage of the intermittently-failing tests are tests for web
features vs. tests for
The site-specific UA override functionality has already landed on
mozilla-central and aurora (bug 782453). See also bug 787054 for its
intended use in b2g.
Gavin
On Wed, Sep 26, 2012 at 7:28 PM, Jonas Sicking wrote:
> On Wed, Sep 26, 2012 at 5:55 AM, Gervase Markham wrote:
>> This is a proposed
On Sat, Sep 29, 2012 at 7:53 AM, Chris AtLee wrote:
> http://people.mozilla.org/~catlee/highscores/highscores.html is a report of
> where our time on Try is going.
I think we should have this data feed into a cronjob that emails the
top ~5 weekly (ab)users of try, notifies them of their impact, a
On Wed, Oct 3, 2012 at 4:33 AM, Mounir Lamouri wrote:
> On 09/29/2012 06:40 PM, Gavin Sharp wrote:
>> On Sat, Sep 29, 2012 at 7:53 AM, Chris AtLee wrote:
>>> http://people.mozilla.org/~catlee/highscores/highscores.html is a report of
>>> where our time on Try is goi
I disagree. "Pushed to inbound" is an important status to have
indicated in the bug, and the best way to do that is to include the
inbound changeset URL (even though it will be the same revision when
it gets to m-c, it's useful to know where it is until it gets there).
It also helps with backouts,
On Mon, Oct 8, 2012 at 3:42 PM, Justin Lebar wrote:
> I don't feel like it's /always/ important.
>
> On a bug that njn and I are the only ones watching and which gets
> landed on m-i over the weekend, it's not at all clear to me that
> anyone is hurting for lack of an explicit notification that th
On Mon, Oct 8, 2012 at 9:05 PM, Gregory Szorc wrote:
> I'm writing this post to see what obstacles/resistance there are to removing
> the make targets for running tests. Obviously a prerequisite is having mach
> reach feature parity with the make targets. What other concerns are there?
Maintainin
This is excellent -
https://developer.mozilla.org/en-US/docs/JavaScript_OS.File/OS.File_for_the_main_thread
is exactly the kind of API I've been wanting for a long time. I know
it took a lot of work to get there - thank you for your efforts.
A couple of questions:
- some examples use file names wi
On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
> Not if the pref isn't set. If the pref is set I suspect it still returns
> an object with the relevant properties, but that object is no longer a
> BackstagePass. I haven't verified that though.
Will that break
http://mxr.mozilla.org/mozilla-c
y wrote:
>> On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp wrote:
>>
>>> On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey wrote:
>>>> Not if the pref isn't set. If the pref is set I suspect it still returns
>>>> an object with the relevant properties, bu
On Wed, Nov 14, 2012 at 10:53 AM, Mounir Lamouri wrote:
> For that, we will need some tools to know if we are building for Release
> (and let say Beta) where the feature should be hidden by default, with
> opposition to Aurora, Nightly or custom builds where the feature should
> be enabled by defa
On Wed, Nov 14, 2012 at 2:23 PM, Mounir Lamouri wrote:
> MOZ_UPDATE_CHANNEL contains a string and AFAIK, we can't use C
> preprocessor to compare strings so it might not be enough.
The common solution is to check MOZ_UPDATE_CHANNEL in the Makefile to
adjust defined variables, see e.g.:
http://mxr
On Mon, Jan 7, 2013 at 1:13 PM, L. David Baron wrote:
> On Monday 2013-01-07 13:02 -0800, Chris Peterson wrote:
>> I've seen some inconsistent usage, so I just wanted to get a group opinion.
>>
>> If a fix for bug X introduces regression bug Y, should Y "block" X
>> (because X is not properly fixe
On Fri, Jan 18, 2013 at 3:18 AM, wrote:
> I noticed that the notifications are sent fine but the nsIObserver only
> receives them when I have a JS/XUL Gui interaction towards _any_ of my C++
> xpcom components.
I'm not sure what "when I have a JS/XUL Gui interaction towards _any_
of my C++ xpc
101 - 159 of 159 matches
Mail list logo
