That's one of the suggestions Dan Stillman makes in his post, and it
seems like a fine idea to me.
Gavin
On Mon, Nov 30, 2015 at 11:15 AM, Jonathan Kew wrote:
> On 30/11/15 15:45, Gavin Sharp wrote:
>>>
>>> and it's definitely the wrong thing to do.
>>
&
#x27;t think it strikes the right balance.
If your proposed alternative plan is something else, maybe it would help to
clarify it.
Gavin
On Mon, Nov 30, 2015 at 9:33 AM, Ehsan Akhgari
wrote:
> On 2015-11-28 2:06 AM, Gavin Sharp wrote:
>
>> The assumption that the validator must catc
Zimmermann wrote:
> Hi
>
> Am 27.11.2015 um 16:50 schrieb Gavin Sharp:
> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham
> wrote:
> >> But the thing is, members of our security group are now piling into the
> >> bug pointing out that trying to find m
I wasn't suggesting that you had made that incorrect assumption.
Gavin
On Sat, Nov 28, 2015 at 10:31 AM, Eric Rescorla wrote:
> On Fri, Nov 27, 2015 at 11:06 PM, Gavin Sharp
> wrote:
>
>> The assumption that the validator must catch all malicious code for
>> add-on s
Gavin
> On Nov 27, 2015, at 8:49 PM, Eric Rescorla wrote:
>
>
>
>> On Fri, Nov 27, 2015 at 4:09 PM, Ehsan Akhgari
>> wrote:
>> On Fri, Nov 27, 2015 at 10:50 AM, Gavin Sharp wrote:
>>
>> > On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrot
On Fri, Nov 27, 2015 at 7:16 AM, Gervase Markham wrote:
> But the thing is, members of our security group are now piling into the
> bug pointing out that trying to find malicious JS code by static code
> review is literally _impossible_ (and perhaps hinting that they'd have
> said so much earlier
See
https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017
if you're wondering about Firefox specifically.
Gavin
On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht wrote:
> Hi,
>
> we're trying to find out what the default window size would be for people on
It's possible this bug was being confused with bug 1195030.
Gavin
On Tue, Aug 18, 2015 at 2:35 PM, Daniel Stenberg wrote:
> On Mon, 17 Aug 2015, Dirkjan Ochtman wrote:
>
>> I have an anecdote, and was wondering if others can corroborate: it
>> seems to me that Nightly's quality has been getting
> 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
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
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
> 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
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
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
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
> 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
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
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.
>
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
+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 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
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
> 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
> 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
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
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
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
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
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
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
> 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
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
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
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.
>
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
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
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
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
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
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
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
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 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 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
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
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 &
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
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
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
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
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 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
> 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 Fri, May 16, 2014 at 5:15 PM, Robert O'Callahan wrote:
> Seems to me we should indicate pings in the link status text (bug 401352),
> indicate pinging in the status text while we load the next page, and retain
> the about:config pref to disable pinging.
> The first two measures seem low-cost a
On Fri, May 16, 2014 at 5:35 AM, Jonathan Kew wrote:
>> You actually don't, since Google doesn't add the tracking stuff to
>> the link until you click it. But it adds it early enough in click
>> handling so that it affects what happens when you click the link.
> Yes; but even if I simply click t
t;
> I think what we should do is confirm that strict warnings as errors is
> actually turned on for xpcshell, and if so, where this happens.
>
> CC'ing bholley, because he probably knows where to look.
>
>
> On 08/05/14 03:45, Gavin Sharp wrote:
>>
>> To elabora
To elaborate:
- Bug 524781 is still open
- I don't see any reference to -werror or -S in runxpcshelltests.py
Gavin
On Wed, May 7, 2014 at 4:48 PM, Gavin Sharp wrote:
>> When xpcshell tests are run, they flip a bit on the initial JSContext that's
>> off by default that te
;t find it MXRing.
Gavin
On Wed, May 7, 2014 at 4:39 PM, Fitzgerald, Nick
wrote:
> On 5/7/14, 4:21 PM, Gavin Sharp wrote:
>>
>> What does "get rid of strict warnings as errors for xpcshell tests"
>> mean in practice?
>
>
> It means that our non-standard spider
On Tue, May 6, 2014 at 1:49 PM, Eddy Bruel wrote:
> I would like to propose that we get rid of strict warnings as errors for
> xpcshell tests. To quote Nick Fitzgerald: "The strict-warnings-as-an-error
> feels like having some arbitrary linter forced upon our development that
> isn't very useful."
I had the same concern in bug 967693. There was some back and forth in
a private email thread (we should have discussed it in the bug...)
that essentially boiled down to "the orange/perf investigations are
blocked, we want more nightly crash/bug reports to work on in parallel
while those are figure
On Wed, Apr 30, 2014 at 6:14 AM, Henri Sivonen wrote:
> As far as I know, there are two issues with XHR when it comes to local
> file input:
> 1) It wants a URL instead of an nsIFile and nsIFile doesn't have a
> getter for a URL pointing to the same file, so there's a mismatch
> between what you
I thought the "performance problems" in question were related to memory
use/worker initialization. But
https://bugzilla.mozilla.org/show_bug.cgi?id=981085#c0 doesn't really have
any useful detail.
Ehsan, what needs were you referring to there, and are they tracked in bugs?
Gavin
On Wed, Apr 30,
Ah right, I had forgotten about those issues. That's in fact exactly the
code that Henri was looking at. XHR would perhaps be better than the XPCOM
IO if it works, but I don't think anyone's done that investigation.
Gavin
On Tue, Apr 29, 2014 at 11:22 AM, Nathan Froyd wrote:
> - Original M
The current best practice for file I/O in privileged JS is OS.File. It
has mechanisms for doing encoding conversion and compressing data.
That there is some b2g code using NetUtil/XPCOM instead is a bug, and
probably was caused by the relevant code being written prior to the
existence of OS.File (o
It would help a lot with bug-clarity if both the "record umask on
startup" and "add API to OS.File" changes were split into their own
bugs. The debate is really about the OS.File API.
The API question depends a lot on the use cases people foresee. Are
there any use cases identified for this API ot
tly. "Every patch must have SR" was
an easy policy to enforce, this one is much trickier.
I don't frankly know how I feel about "the value of SR" today. I'm curious
what others think.
Gavin
On Thu, Apr 24, 2014 at 4:31 PM, Bobby Holley wrote:
> On Thu, Apr
Those asides are precisely the reason it's "abuse" :)
We should update the list, but from a quick skim I think there aren't
more than 2-3 names on that list that need removing. Part of the
problem might be solved by introducing an "superreviewer emeriti"
list.
Gavin
On Thu, Apr 24, 2014 at 3:36
The question was simply "are there non-tracking use-cases for sendBeacon",
and it sounds like the simple answer is "yes". Still not clear how common
they will be relative to the tracking use cases in practice, though. What
we do in terms of UI and exposing the ability to disable it depends on
bette
The code in toolkit/components/help is only used by SeaMonkey, as far
as I can tell.
I think you can archive that article.
Gavin
On Wed, Apr 16, 2014 at 2:05 PM, Eric Shepherd wrote:
> I'm continuing our documentation cleanup, and found this article:
>
> https://developer.mozilla.org/en-US/docs
On Wed, Apr 16, 2014 at 8:56 AM, Ehsan Akhgari wrote:
>> Are beacons primarily meant as tracking devices, or is it also meant as
>> a way to persist unsaved page state when the user navigates?
> Beacons do not enable any new ways of tracking which is not already
> possible.
That's not an answer
On Sun, Apr 13, 2014 at 10:01 PM, Karl Tomlinson wrote:
> Very often I've found that the intended approach changes during the
> life of a bug, and there is no clear summary in the bug of what
> eventually was done. It is then necessary to go back through
> multiple revisions of the patch and asso
I see only two real goals for the proposed policy:
- ensure that module owners/peers have the opportunity to object to
any "disable test" decisions before they take effect
- set an expectation that intermittent orange failures are dealt with
promptly ("dealt with" first involves investigation, usua
On Fri, Apr 4, 2014 at 12:12 PM, L. David Baron wrote:
>> Escalation path:
>> 1) Ensure we have a bug on file, with the test author, reviewer, module
>> owner, and any other interested parties, links to logs, etc.
>> 2) We need to needinfo? and expect a response within 2 business days, this
>> s
On Fri, Mar 21, 2014 at 7:40 AM, Irving Reid wrote:
> extensions.blocklist.pingCountVersion (146 times out of ~1.5 million Nightly
> telemetry sessions) and extensions.shownSelectionUI (8 times in 1.5m)
> The prefs in question aren't likely targets for malware, though they could
> be collateral d
On Thu, Mar 20, 2014 at 10:38 AM, Irving Reid wrote:
> For unknown reasons, internal bookkeeping prefs used by AddonManager and
> XPIProvider are set to values of the wrong type on some Firefox profiles,
> and are now stuck that way. I can write wrapper code on these calls to catch
> the error and
> Another issue, are you planning to upstream your work to Mozilla in the
> near future?
Regardless of intent, I don't think any OS/2 support patches should be
accepted in mozilla-central. A platform port like that is too "high
touch" and low-value to be worth the maintenance burden in
mozilla-cen
Whose workflow requires calling mach not in an objdir or srcdir? That
seems crazy and no one should do it!
Similarly, it seems like all of the ambiguous cases you mention should
be aborts, because I don't know of any reasonable cases where someone
would be in that situation, and "picking one" just
I'm sure there are other use cases, but the most common one for me is
using it to sort out tracking flags for regressions and otherwise
complicated dependency trees.
Gavin
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson wrote:
> On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
>>
>> I think the "Target
(It's probably a good idea scope this discussion to common practice in
the "Firefox" components i.e. Core/Firefox/Toolkit/etc. Bugzilla
discussions like this one can get into the weeds pretty quickly when
people bring up other projects who use our Bugzilla installation and
who have different practi
I support getting rid of NS_ENSURE_*.
Gavin
On Tue, Jan 7, 2014 at 3:13 AM, Ms2ger wrote:
> On 01/07/2014 01:11 AM, Joshua Cranmer 🐧 wrote:
>>
>> On 1/6/2014 6:06 PM, smaug wrote:
>>>
>>> On 01/07/2014 01:38 AM, Joshua Cranmer 🐧 wrote:
On 1/6/2014 4:27 PM, Robert O'Callahan wrote:
Seems like it would be a good idea to update
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#C.2FC.2B.2B_practices
accordingly.
Gavin
On Mon, Jan 6, 2014 at 10:12 AM, Ehsan Akhgari wrote:
> With Birunthan's restless efforts in bug 784739, we have finally removed
> the usage
am Roach wrote:
> On 1/6/14 09:50, Gavin Sharp wrote:
>
>> A concise summary of the changes you're proposing would be useful -
>> here's my attempt at one.
>>
>> From what I gather, the changes you're proposing to the style guide are:
>>
>>
A concise summary of the changes you're proposing would be useful -
here's my attempt at one.
>From what I gather, the changes you're proposing to the style guide are:
* remove implicit discouragement of changing code to conform to "Mozilla style"
** style changes should never be combined with fu
This seems better targeted to firefox-dev
(https://wiki.mozilla.org/Firefox/firefox-dev), or even more
specifically to the DevTools list
(https://lists.mozilla.org/listinfo/dev-developer-tools).
Gavin
On Tue, Dec 3, 2013 at 7:43 AM, Sebastian Zartner
wrote:
> The Firebug users are currently expe
On Thursday, November 28, 2013, Henri Sivonen wrote:
> Do we have policy reasons that preclude A/B testing on Release or Beta?
>
We don't have any policies against it; just some FUD from not having a
precedent :)
Doing A/B testing on release is something I'm very interested in exploring
further.
I'm in the same boat - I use it relatively frequently to look up history.
Part of this is a form of habit - there are alternatives ways to get
at (most of?) that history now.
But I would be interested to know more about what killing it gains us,
in order to better evaluate the tradeoff.
Gavin
O
It would be good to explore alternatives to Bonsai.
https://github.com/mozilla/mozilla-central is supposed to have full
CVS history, right?
Some concerns with that alternative:
- I think that repo misses some history from some branches of CVS
- I'm not confident that we've audited that whatever hi
(firefox-dev is a better venue for this question, redirecting there)
We don't currently have any active plans for "persistent tabs".
Pinned tabs should be difficult to accidentally close since Firefox 4
(bug 580638), though, so I wonder why they don't address your use
case.
Gavin
On Mon, Nov 18
On Thu, Oct 31, 2013 at 1:55 AM, Avi Hal wrote:
> Essentially the browser has become an operating system, where apps/addons
> could be installed to it, including malwares. However, consider what happens
> if
> Microsoft or Apple would not let any app run unless it's approved on their
> main
> de
We removed the feature that allows users to easily restart in 32-bit
mode in https://bugzilla.mozilla.org/show_bug.cgi?id=850925 (Firefox
22).
Gavin
On Tue, Oct 22, 2013 at 6:27 AM, Philip Chee wrote:
> On 22/10/2013 01:14, Ehsan Akhgari wrote:
>> Note that we also use this to support 32-bit plu
https://bugzilla.mozilla.org/show_bug.cgi?id=893404 and
https://bugzilla.mozilla.org/show_bug.cgi?id=898825 are two of the last
parent-process crash bugs in the current e10s-crash list
(https://bugzilla.mozilla.org/show_bug.cgi?id=899758). Drew and I are planning
to let the background thumbnail
On Wed, Oct 9, 2013 at 4:28 PM, Philipp Kewisch wrote:
> I think its the wrong conclusion, shouldn't we rather be fixing security
> holes and analysing the code for vulnerabilities than removing random things
> just because of their potential risk?
Those options are not mutually exclusive; we sho
On Fri, Sep 20, 2013 at 3:07 PM, Patrick Brosset wrote:
> docShell.getSameTypeParentIgnoreBrowserAndAppBoundaries() doesn't return
> null, it returns a docShell, but the subsequent querySelectorAll("iframe")
> call returns an empty array.
You can have a child docshell in a container other than "i
On Fri, Sep 20, 2013 at 11:14 AM, Patrick Brosset wrote:
> When the site loads, we listen to (using nsIWebProgressListener) state
> changes and for each window that completes loading, we call a helper
> function that'll tell us if that window is the website's top one or not.
Can't you use aWebPro
On Fri, Sep 20, 2013 at 12:24 PM, Paul Rouget wrote:
> @all: Is there a way to know which DOM element holds a docShell? Basically,
> which
> owns the docshell?
Sounds like you want a scriptable (privileged-only) version of
nsIDOMWindow realFrameElement
Gavin
__
I remember discovering some of this confusing behavior while working
on bug 391834. It dates back to bug 61098, and following the reasoning
from those bug comments is a bit tricky. jst or Natch might recall the
details, but I doubt it :)
I wouldn't really assume that there's some great reason for
On Mon, Sep 16, 2013 at 6:04 AM, Aryeh Gregor wrote:
> Probably the findbar code should continue implementing its own
> checking, unless you're aware of other actual consumers that could
> reuse the same code.
I agree, I don't think that we should be shooting for some generic
solution. But we do
On Mon, Sep 16, 2013 at 5:12 AM, Aryeh Gregor wrote:
> The real question is: what's the use-case you're trying to solve? If
> it's some sort of optimization, false positives should be okay.
The find bar wants to avoid finding "hidden" text, AIUI (see bug
257061). Some false positives would certa
On Mon, Sep 9, 2013 at 10:08 PM, Scott Johnson wrote:
> I'd recommend we not do this, as it will likely break hg blame.
I think the idea that white space-only changes "break hg blame" needs
to die :) White space-only changes are a change like any other, and at
worst add one step to what is usuall
On Mon, Sep 9, 2013 at 10:15 AM, ishikawa wrote:
> So my question boils down to
> - what is the preferred style for JavaScript now for mozilla source code?
There isn't one that applies across all of Mozilla, and I think that's
not a problem.
(https://developer.mozilla.org/en-US/docs/User:GavinS
1 - 100 of 159 matches
Mail list logo
