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
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
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
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
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
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
#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
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.
>>
&
On Tue, Mar 5, 2013 at 10:43 AM, Bobby Holley wrote:
> I don't really have faith in our ability to "evangelize heavily" on this
> issue (outside of what we've already done) without flipping the switch.
> This is why I want to ship it, figure out which sites are broken, and only
> put in shims if w
On Tue, Mar 5, 2013 at 11:33 AM, Bobby Holley wrote:
> This makes sense in terms of |if (Components)| browser detection. But if a
> site is grabbing interface constants off of nsIDOMFoo interfaces, it seems
> very unlikely that said site would work in another browser.
This line of reasoning can b
On Tue, Mar 5, 2013 at 11:42 AM, L. David Baron wrote:
> That said, making different implementations of the Web platform
> (i.e., different browsers) converge so that authors can rely on
> standard behavior is a goal. The pieces of that that we have
> control over are adding and removing things f
Re-directing this question to dev-platform.
Gavin
On Fri, Mar 8, 2013 at 7:13 AM, Jaime Hablutzel Egoavil
wrote:
> rfc2388 states:
>
> The original local file name may be supplied as well, either as a
> "filename" parameter either of the "content-disposition: form-data" header
> or, in the case
On Thu, Apr 11, 2013 at 2:15 AM, Marco Bonardo wrote:
> The TM set on landing is something we do from many years, as far as i
> remember could be like 4 years, and surely we started doing that more
> consistently with rapid release cycle. I'd say 80% of the developers are
> aware of this, so not s
On Thu, Apr 11, 2013 at 10:23 AM, Justin Dolske wrote:
> For example: "Fixed from this version on" could be a static display derived
> from "status-firefox#" flags... Find the earliest "fixed" state without
> later non-fixed states.
I think we need to maintain the distinction between "landed on t
The only possibly-related code I see in Firefox's "Forget about this
Site" functionality is this:
http://hg.mozilla.org/mozilla-central/annotate/261d6997d1d1/toolkit/forgetaboutsite/ForgetAboutSite.jsm#l179
Which uses nsIQuotaManager. A quick look at the implementation
suggests it doesn't cover "
On Mon, Apr 15, 2013 at 9:50 AM, Gavin Sharp wrote:
> The only possibly-related code I see in Firefox's "Forget about this
> Site" functionality is this:
>
> http://hg.mozilla.org/mozilla-central/annotate/261d6997d1d1/toolkit/forgetaboutsite/ForgetAboutSite.jsm#l179
>
I think Rob was talking about the case where you would call e.g.:
"mach build browser/base"
mach could know that on Mac, that also requires the equivalent of
"mach build browser/app" for those changes to actually be repackaged
into the bundle in objdir/dist/, because the build system doesn't. Of
On Tue, Apr 23, 2013 at 8:41 AM, Chris AtLee wrote:
> We've considered enforcing this using some cryptographic token. After you
> push to try and get good results, the system gives you a token you need to
> include in your commit to m-i.
Sounds like the goal of this kind of solution would be to e
On Tue, Apr 23, 2013 at 9:28 AM, Kartikaya Gupta wrote:
> Not trivial, but not too difficult either. Do we have any evidence to show
> that the try highscores page has made an impact in reducing unnecessary try
> usage?
It's been used by people like Ed Morley to reach out to individual
developers
On Fri, Apr 26, 2013 at 11:36 AM, Andreas Gal wrote:
> Preferences are as the name implies intended for preferences. There is no
> sane use case for storing data in preferences. I would give any patch I come
> across doing that an automatic sr- for poor taste and general insanity.
As Greg sugge
On Fri, Apr 26, 2013 at 12:10 PM, Benjamin Smedberg
wrote:
> I really hope the outcome of this discussion is that we end up storing
> everything that isn't a true preference in some other datastore, and that is
> an async-by-default datastore ;-)
> With a pretty simple JSM wrapper, indexeddb coul
Bug 864085
On Fri, Apr 26, 2013 at 2:06 PM, Kartikaya Gupta wrote:
> On 13-04-26 11:37 , Phil Ringnalda wrote:
>>
>> Unfortunately, engineering is totally indifferent to
>> things like having doubled the cycle time for Win debug browser-chrome
>> since last November.
>>
>
> Is there a bug filed
On Fri, Apr 26, 2013 at 2:16 PM, Kartikaya Gupta wrote:
> Lately I've run into this a few times, where I see regressions on
> areweslimyet.com and dig into it, only to find the regression happened on a
> "merge from m-c" changeset. Since the mobile AWSY only runs on m-i (on the
> theory that I get
I believe bz's theory is that the 's binding was being
force-applied because the was being wrapped to be passed to
your JS-implemented content policy (as aContext). XBL bindings are
force-applied when an element in a document is JS-wrapped and its
binding hasn't yet been applied through normal mec
I suppose you could say it's a bug in the browser binding. Worth filing, CC me?
Gavin
On Sat, May 11, 2013 at 2:26 PM, Matthew Gertner
wrote:
> On Saturday, May 11, 2013 7:37:00 PM UTC+2, Gavin Sharp wrote:
>> I believe bz's theory is that the 's binding was being
>
On Wed, May 15, 2013 at 4:00 PM, Gregory Szorc wrote:
> Ahh, I was thinking more of JS services. In this world, your manifest adds
> an entry to the "app-startup" category and your service receives the
> "app-startup" notification. It is customary for it to register an observer
> for a later start
Can't you just avoid calling openPopup until the page is loaded, and
avoid messing with the panel's "hidden" state completely?
Gavin
On Thu, May 16, 2013 at 8:27 AM, Matthew Gertner
wrote:
> I have a toolbar button that displays a XUL panel when pressed. The panel
> contains an iframe into whic
[redirecting this to dev-platform only]
On Fri, May 17, 2013 at 8:29 AM, Benjamin Smedberg wrote:
> On 5/16/2013 8:04 PM, Gavin Sharp wrote:
>
>> Bug 853071 landed in the Firefox 23 cycle, adding some defines that make
>> it possible to control when in the release cycle code is
, wherever possible (and where not possible,
file a bug to investigate adding a define that better addresses the
specific use case). Bug 875342 is one such example.
Gavin
On Thu, May 16, 2013 at 5:04 PM, Gavin Sharp wrote:
> Bug 853071 landed in the Firefox 23 cycle, adding some defines that m
On Tue, Jun 18, 2013 at 8:10 AM, David Rajchenbach-Teller
wrote:
> If I understand correctly, we are doubling both network and disk
> activity (possibly CPU activity, too) for this purpose. Performance- and
> battery-wise, that's not a very good idea.
"doubling" for the thumbnails we capture usin
On Tue, Jun 18, 2013 at 8:00 AM, Nicolas Silva wrote:
> I feel somewhat uneasy about the idea that thumbnails generate more network
> traffic. It would be great to at least throttle that when connectivity is
> bad, or when the the user's data plan bill could suffer from it (not sure
> how to detec
On Tue, Jun 18, 2013 at 10:12 AM, Nicolas Silva wrote:
> Then we should really measure network traffic impact and take it into
> account when we decide to ship it on mobile platforms.
I don't think there's any plan to make use of this for non-desktop at
the moment (IIRC Metro was interested). But
On Tue, Jun 18, 2013 at 10:21 AM, Jorge Villalobos wrote:
> Would it make sense to come up with a standard way for sites to offer
> their own screenshots, in a similar way that favicons are offered?
It would be nice, but difficult. Without consistency in how the
thumbnails are used, and without a
On Tue, Jun 18, 2013 at 3:29 PM, David Rajchenbach-Teller
wrote:
> I don't understand when we wouldn't use this service. At the moment, we
> capture thumbnails for all pages, so if we do not change that strategy,
> the sandbox would effectively double at least all non-ajax network/disk
> activity.
The message you quote has a specific example - "Mozillians who have
experience designing JS APIs and will have at least one representative
from the JS team at all times" is probably not the best group to
determine whether we should implement support for/ship SPDY, for
example. I think it's clear th
The scope of the current proposal is what's being debated; I don't think
there's shared agreement that the scope should be "detectable from web
script".
Gavin
On Wed, Jun 26, 2013 at 11:01 AM, Ehsan Akhgari wrote:
> On 2013-06-26 1:38 PM, Gavin Sharp wrote:
>
.sOn Mon, Jul 1, 2013 at 10:58 AM, Benjamin Smedberg
wrote:
>> Idempotent: Currently Gecko's parser and the URL Standard's parser are
>> not idempotent. E.g. http://@/mozilla.org/ becomes
>> http:///mozilla.org/ which when parsed becomes http://mozilla.org/
>> which is somewhat bad for security. M
Seeing the filing of bug 895340 pushed me over the edge, because I knew we
had many other similar bugs on file about unreported JS exceptions.
I ended up filing https://bugzilla.mozilla.org/show_bug.cgi?id=895548, a
tracking bug from which I could link a bunch of other related bugs that I
found.
Gecko 24, https://bugzilla.mozilla.org/show_bug.cgi?id=872421
On Mon, Jul 22, 2013 at 9:53 AM, Jorge Villalobos wrote:
> On 7/19/13 3:21 AM, David Rajchenbach-Teller wrote:
>> This is a short announcement: chrome workers now support modules. For
>> your future developments involving chrome worker
On Thu, Jul 25, 2013 at 10:25 AM, Justin Lebar wrote:
> Unless you have an inside the , and it's
> that that you were setting as an app? If that's the case,
> could you merge the and ? (You could
> either use a or an .)
As I understand it this is the case. From Mark's original post:
>> The
On Mon, Jul 29, 2013 at 1:28 PM, Gijs Kruitbosch
wrote:
> On 29/07/13 21:53 , Anne van Kesteren wrote:
>> The current thinking is
>> that offering developers the primitives will give us a better higher
>> level API longer term.
>
> Isn't that reasoning part of why we are now in the position where
On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan wrote:
> On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp wrote:
>> Indeed. Somewhat off-topic for this thread, but I think this "let's
>> provide primitives and let other people build higher-level libraries"
&g
On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarsky wrote:
> On 7/30/13 11:13 AM, Dave Townsend wrote:
>>
>> The JS promise implementation came out of a desire to use promises in
>> add-ons and devtools amongst others. I believe the C++ implementation came
>> out of the DOM spec. I'm not sure why we n
I've mentioned this at the engineering meeting, but thought it worth a note
here just to ensure everyone is aware:
Bug 870100 enabled use of the background thumbnail service in Firefox
desktop, which uses a to do thumbnailing of pages in
the background.
That means that desktop Firefox now makes
ngs that
> would cause a crash if JS code can invoke random dom apis. I however
> very happy that we are testing in a limited
> fashion with this.
>
> Tom
>
> On Tue, Jul 30, 2013 at 7:10 PM, Gavin Sharp wrote:
> > I've mentioned this at the engineering meeting, but
On Thu, Aug 1, 2013 at 4:38 PM, Mike Hommey wrote:
> There have been OS/2-related changes landing way after that date, so I
> doubt it is actually broken. In fact, there's been an OS/2 specific
> landing a week ago (!).
Bug 501496 and bug 712105 were pretty mechanical changes that just
mirrored c
seeing them in a tab? I don't appear to see this
> on an old nightly24 snapshot I have lying around.
>
> -Jeff
>
> ----- Original Message -
> From: "Gavin Sharp"
> To: "dev-platform"
> Cc: "firefox-dev"
> Sent: Tuesday, July 30,
On Thu, Aug 1, 2013 at 6:24 PM, Nicholas Nethercote
wrote:
> On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp wrote:
> > Seems likely, I recall markh mentioning something similar - adblock
> probably
> > doesn't work in the content process.
>
> That seems... less than i
t; wrote:
>
>> On Thu, Aug 1, 2013 at 5:46 PM, Gavin Sharp wrote:
>> > Seems likely, I recall markh mentioning something similar - adblock
>> probably
>> > doesn't work in the content process.
>>
>> That seems... less than ideal. I don't th
On Thu, Aug 1, 2013 at 6:50 PM, Nicholas Nethercote
wrote:
> Huh? This sentence seems entirely antithetical to our standard
> operating procedure. I.e. backing out known regressions, etc.
What "known regression" are you referring to here? Ads on thumbnails?
That seems like a much less serious p
As I commented in bug 770316, splitmenus aren't really a supported
part of the general platform, and I think we will remove them soon. So
I would discourage you from using them further, if possible :)
Gavin
On Thu, Sep 5, 2013 at 2:42 PM, Jan Odvarko wrote:
> Two questions about element:
>
> #1
On Fri, Sep 6, 2013 at 1:32 PM, Nicholas Nethercote
wrote:
> With the above code I do get an iframe that loads about:about, which
> is good. But there's no child process created, and when I inspect the
> |remote| attribute of the iframe it is |undefined|, as if something
> prevented it from being
Here are a few examples of mocked components:
http://mxr.mozilla.org/mozilla-central/source/testing/specialpowers/content/MockPermissionPrompt.jsm?force=1
mocks nsIContentPermissionPrompt
http://mxr.mozilla.org/mozilla-central/source/dom/tests/mochitest/bugs/test_bug61098.html?raw=1
mocks nsIProm
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
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 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 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
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 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
__
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 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 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
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
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
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
(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
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
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.
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
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
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:
>>
>>
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:
(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'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
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
> 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
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
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 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
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 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
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
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
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
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
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
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
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
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
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,
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 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 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."
;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
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;
> 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
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
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
1 - 100 of 159 matches
Mail list logo
