Re: Any plans to move the bug re. low cipher strength in Firefox' master password forward one day?

Yes, we're looking at it, but don't have a detailed plan or schedule to share yet. Justin On Wed, Oct 3, 2018 at 10:40 AM Jörg Knobloch wrote: > Hi all, > > an unrelated discussion made me aware that the master password cipher > strength bug[1] is still open. Any plans to tackle that? > >

Re: WebRender on in Firefox Nightly for Windows 10 Nvidia

\o/ Congrats on this major milestone! Exciting times for Firefox ahead! :D Justin On Wed, Sep 12, 2018 at 1:38 PM, Jean-Yves Avenard wrote: > What an achievement… > > Congrats to you and the team…. > > JY > > > On 12 Sep 2018, at 10:07 pm, Jeff Muizelaar > wrote: > > > > In bug 1490742 I have

Re: PSA: Major preference service architecture changes inbound

I know we've had code that, instead of reading a pref directly, checks the pref once in an init() and uses pref observers to watch for any changes to it. (i.e., basically mirrors the pref into some module-local variable, at which point you can roll your own locking or whatever to make it

Re: Yes=0, No=1

On Thu, Jul 12, 2018 at 1:28 PM, Jason Orendorff wrote: > > ...This is bad, right? Asking for a friend. > > 1 Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: New prefs parser has landed

Wow. Some of that is bizarre enough that I kinda want to go look at the old parser code, but I value my sanity enough to not do so. Nice work. Can I presume that things which now trigger parsing issues are escaped or errored by the relevant prefs APIs? e.g. if a caller tries to set a pref name or

Re: Change in the way e10s and multi are enabled on Nightly

On Wed, Oct 18, 2017 at 11:52 AM, Blake Kaplan wrote: > > One more thing to point out: with the removal of e10srollout, I also > removed the code that would disable e10s if we detected a > non-multiprocessComptaible extension. We are entirely relying on the addon > manager to

Photon Engineering Newsletter #16

(via https://dolske.wordpress.com/2017/09/22/photon-engineering-newsletter-16/) Time to get your groove on! It’s Photon Newsletter #16 ! But first. Do you remember the 21st night of September ? As of today

Photon Engineering Newsletter #15

I’m back from a vacation to see the eclipse , so it’s time for Newsletter #15 ! (It’s taking me some time to get caught up, so this update covers the last 2 or so weeks.) As noted in my previous

Photon Engineering Newsletter #12

(via https://dolske.wordpress.com/2017/08/13/photon-engineering-newsletter-12/ ) Let’s get straight into update #1 2 ! Oh, hey, anyone notice any icon chances recently? Yeah, they’re pretty wonderful. Or

Photon Engineering Newsletter #11

(via https://dolske.wordpress.com/2017/08/04/photon-engineering-newsletter-11/ ) H*ck yeah, it’s time for another Photon newsletter! They now go to #11 ! It’s Hip To Be Square So… Perhaps you noticed something ever so slightly different in yesterday’s

Photon Engineering Newsletter #10

(via https://dolske.wordpress.com/2017/08/01/photon-engineering-newsletter-10/ ) Woo yeah! Time for Photon newsletter #10 ! Nightly-57 this week Way back in newsletter #2

Photon Engineering Newsletter #9

(via https://dolske.wordpress.com/2017/07/24/photon-engineering-newsletter-9/) Well, here we go again with a big update for Newsletter #9 ! [Since the last update, I took a vacation and ever since have been getting caught up. So this update is terribly

Photon Engineering Newsletter #8 (Super Ultra Mega All-Hands edition)

(via https://dolske.wordpress.com/2017/07/05/photon-engineering-newsletter-8/) Oh boy ! Do I have some great updates for Newsletter #8 ! But seriously, this is a huge update… San Francisco All-Hands [image:

Photon Engineering Newsletter #7

(via https://dolske.wordpress.com/2017/06/22/photon-engineering-newsletter-7/ ) Lucky you, here’s Photon update #7 ! Let’s start off with a fresh new video that gives an overview of what we’re doing with the Quantum and Photon projects. If you’re

Photon Engineering Newsletter #6

(via https://dolske.wordpress.com/2017/06/15/photon-engineering-newsletter-6/) More exciting progress this week! Here’s Photon update #6 ! New Menus Work on the new Photon menus has reached the point where we’re ready to turn them on by default (for

Photon Engineering Newsletter #5

Via https://dolske.wordpress.com/2017/06/08/photon-engineering-newsletter-5/ Time for a solid update #5 ! So far the Photon project appears to be well on track — our work is scoped to what we think is achievable for Firefox 57, and we’re generally

Photon Engineering Newsletter #3

(via https://dolske.wordpress.com/2017/05/30/photon-engineering-newsletter-3/) Three! Time for update number three! Ah-ah-ah… Let’s get straight to it. Recent Changes Menus/structure: - Work on the new application menu is nearing completion. Edit

Photon Engineering Newsletter #2

(via https://dolske.wordpress.com/2017/05/23/photon-engineering-newsletter-2/) That’s right! Time for another Photon Engineering Newsletter! (As I gradually catch up with real-time, this update covers through about May 16th). May got off to a busy start for the Photon team. As I mentioned in

Re: Quantum Flow Engineering Newsletter #5

On Tue, Apr 18, 2017 at 4:22 PM, Ehsan Akhgari wrote: > All in all we have a lot of ongoing projects and they each have > different scales and different degrees of risk associated with them, and > we are trying hard to be really careful on what project depends on what >

Re: Quantum Flow Engineering Newsletter #5

On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt wrote: > > Another really nice effort that is starting to unfold and I'm super > excited > > about is the new Photon performance project > > , which is a > focused > > effort on

Re: unowned module: Firefox::New Tab Page, help me find an owner

Can you follow up with me in separate email about what posts you're concerned about? I've done most of the rejection moderation on the list, and usually reply to people explaining why and where a better venue would be. Most stuff that has been moderated is exactly what's listed there as being

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

It would be useful to know if most of those users are just downgrading the previous version (N-1 for release, N-7 for ESR), and how quickly they return to a current release (assuming they do!). This would help inform to what degree we need to support (and test!) the myriad combinations of

Re: The future of commit access policy for core Firefox

Similar to "r+ with fixes" are cases where a patch (or patch series) requires reviews from a multitude of people. Which means variable delays in getting reviews, during which things may slightly bitrot or be trivially modified based on feedback from other reviewers. Code refactorings are one

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

Do we have any data on existing content usage of -moz-appearance? Or is this a "ship it and see what breaks" kind of thing? I have the vague recollection that this is something that might have non-trivial usage (especially and specifically "-moz-appearance: none"), so just want to make sure

Re: Intent to implement: HTML5 element

What's the expected experience if chrome code uses this feature? (In a chrome window, interaction with a content window isn't the thing I'm wondering about.) Justin On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen wrote: > *Summary*: > The *HTML element* represents a dialog box

Re: Visual Studio 2017

Until we officially support it, can we have mach print out a warning (w/ link to a bug number or wiki page) if you try to build with it? (And, of course, with some opt-in mechanism to use it anyway.) ISTR in the past it was relatively common for people who upgraded (or were just installing the

Re: Removal of B2G from mozilla-central

On Fri, Sep 30, 2016 at 3:31 AM, Gabriele Svelto wrote: > > Since gonk is a widget on its own, during the internal discussions about > it I - and others who worked on B2G - repeatedly asked for the gonk > widget to be left in the code even after the removal of all the >

Re: Reproducible builds

On Sun, Jul 17, 2016 at 9:38 AM, David Bruant wrote: > > The second point sort of solves them both. As part of making things > verifiable, Mozilla could publish a program that makes byte by byte > comparison only on files that matters after unzip. If they're not that >

Re: MXR permanently offline, please transition to DXR

This reminds me of a password manager bug we fixed 9 years ago (379997!), where password manager would "helpfully" delete a saved HTTP login if it got a 403 response upon using it. Unsurprisingly, this was a a terrible idea that caused your saved logins to disappear when a site was glitchy. Seem

Re: [Go Faster] WebCompat Go Faster Add-on

t;cpr...@mozilla.com> wrote: >> >>> >>> On Mon, Jun 27, 2016 at 11:05 AM, Justin Dolske <dol...@mozilla.com> >>> wrote: >>> >>>> What's the policy for reviews and testing with this addon? >>>> >>> >>> You

Re: WebCompat Go Faster Add-on

What's the policy for reviews and testing with this addon? Justin On Mon, Jun 27, 2016 at 10:51 AM, Mike Taylor wrote: > As discussed in the "Platform + Web Compat" session in London, the > webcompat team intends to build a Go Faster Add-on to give us the ability > to

Re: Intent to implement and ship: "passive" option for AddEventListenerOptions

How will a developer know when it would be worthwhile to mark their event listener as passive? Do we perhaps log something to the console? Justin On Wed, May 4, 2016 at 3:19 PM, Kartikaya Gupta wrote: > Summary: Authors can declare in their addEventListener call that the >

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/3/16 12:21 PM, Gregory Szorc wrote: * The update server has been reconfigured to not serve Nightly updates to 10.6-10.8 (bug 1269811) Are we going to be showing some kind of notice to affected users upon Release? That is, if I'm a 10.6 user and I update to Firefox 48, at some point

Re: Changes to bugzilla "plugins" product

It's fine to keep it as-is for now, but I think the goal should be to get rid of it (and possibly Tech Evangelism :: Addons too) for the same reasons as Benjamin noted in his first email. Seem like most of this component's original intent (naming aside) is covered by those new components.

Re: Changes to bugzilla "plugins" product

Will Firefox :: Extension Compatibility also be rolled into this new :: Other component? (There are ~700 open bugs there still, most of which look pretty stale.) Justin On Mon, May 2, 2016 at 11:53 AM, Benjamin Smedberg wrote: > There used to be a bugzilla.mozilla.org

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

On 4/30/16 1:26 PM, L. David Baron wrote: So I think we should take option a': Drop XP and Snow Leopard support on trunk and push ESR builds to the non-ESR update channel on XP and Snow Leopard through the life of 45 ESR. I think enough of our users are on Windows XP that decisions about

Re: [Bug 1224726] High memory consumption when opening and searching a large Javascript file in debugger.

On 4/11/16 4:06 PM, Lawrence Mandel wrote: On Monday, 11 April 2016, Mike Taylor wrote: On 4/11/16 5:04 PM, Mats Palmgren wrote: He touched 283 bugs in the last 48 hours, most of which are FIXED. If anyone in the QA org reads this list, maybe they could reach out and

Re: Triage Plan for Firefox Components

A few comments, although I think others have touched on some of this already. I think my biggest concern is that this is conflating triage and prioritization, which complicates things and introduces ambiguity. For example, what would it even mean to have a "triage: fix-now" bug that's also a P5?

Re: MOZ_LOG_FILE and MOZ_LOG_MODULES are now the environment variables for logging

On 3/24/16 9:54 AM, Ralph Giles wrote: On Mon, Mar 21, 2016 at 9:13 AM, Honza Bambas wrote: tl;dr: Start migrating to use of MOZ_LOG_* instead of NSPR_LOG_*. Don't worry about backward compatibility tho, when MOZ_LOG_* is not set, we fallback to NSPR_LOG_* values.

Re: Intent to implement: W3C WebAppSec credentialmanagement API

On 3/14/16 3:01 PM, Martin Thomson wrote: The actual benefit is something that is only realized once a site puts in the effort required. That is small, yes, but we're seeing sites actively avoid password managers, hence the aggressive heuristics, and rAC is much more likely to work for that,

Re: Intent to deprecate: MacOS 10.6-10.8 support

I don't think it's entirely unfair -- both sets of numbers have their place. OS X is an important platform, but it's also true that these older OS X releases represent a tiny portion of our overall userbase. For a few more data points... Back in Firefox 16 when we dropped 10.5 -- another

Re: Removing Windows AutoDial aka Remote Access Services

It being an IE-ism, only used by .015% of sessions, and with a easy workaround make this sound like and open-and-shut case of "dead". Justin On Fri, Feb 19, 2016 at 4:01 PM, Martin Thomson wrote: > On Fri, Feb 19, 2016 at 1:07 PM, Patrick McManus >

Re: rr chaos mode update

On 2/14/16 9:25 PM, Bobby Holley wrote: How far are we from being able to use cloud (rather than local) machine time to produce a trace of an intermittently-failing bug? Some one-click procedure to produce a trace from a failure on treeherder seems like it would lower the activation energy

Re: Touch events enabled on Windows desktop (nightly only)

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

Re: about:profiles and the new profile manager

On 12/18/15 1:51 PM, Benjamin Smedberg wrote: Have you consulted anyone from the Firefox front-end or Firefox UX team about this already? As it stands, this is not intended to be product code and so I specifically advised Andrea not to spend UX/product time on this. It is still a strict

Re: Proposal to a) rewrite Gecko's encoding converters and b) to do it in Rust

On 12/14/15 2:51 AM, Ted Mielczarek wrote: [...]Obviously this isn't something we like to see, but we shouldn't let the support of non-Tier 1 platforms guide our decision making to that extent. Enabling Rust components in Gecko is important work, and outweighs the value of supporting Firefox on

Re: Intent to implement and ship: FIDO U2F API

On 12/2/15 6:48 AM, Richard Barnes wrote: My initial intent was to propose implementing [1], then implementing [2] when it's ready. After all, there's a lot in common, and as you say, the W3C version will be much nicer. This seems like like a strange path to take. Why implement both? From

Re: Faster Windows builds everywhere!

On 12/1/15 12:41 PM, Chris AtLee wrote: Last week we made the same change to the rest of the Windows build infrastructure. All our Windows builds are now running in AWS. We're seeing good performance gains there too. On mozilla-inbound, we've reduced opt build times by at least 45 minutes, and

Re: Merging comm-central into mozilla-central

On 10/23/15 10:22 AM, Benjamin Smedberg wrote: I'm sorry that it makes you sad, but Mozilla has explicitly decided to prioritize the bar to entry for Firefox development, and the speed of development of Firefox, at the expense of Thunderbird (and seamonkey). And as Firefox development moves

Re: Building js/xul/css from Firefox faster

Nice! Out of curiosity, how does "faster" work? Does it just ignore build targets/directories that involve native code? FWIW, I benchmarked various no-changes builds with yesterday's m-c, on my low-end Surface Pro 3 (i3, 4GB)... mach build: 7:38 mach build browser: 0:43 mach build toolkit: 1:42

Re: dialog=1 for window.open from content

On 10/1/15 1:34 PM, Mike Conley wrote: I'm currently working on bug 1095236 - that's an e10s bug for us failing to open any windows if the features string includes dialog=1 (or dialog=yes). According to [1], setting dialog=1 makes a popup window that removes the min/max/restore buttons, and no

Re: About static analyzers on some various projects

On 9/25/15 7:06 AM, Robert O'Callahan wrote: [...]I'm not quite sure what it would take to get those build failures to appear in MozReview but it should be possible. The tricky bit is to determine which failures were introduced by the patch, and just display those, and display them in the

Re: Considering dropping Talos support for Linux32

On 9/24/15 6:55 PM, Robert O'Callahan wrote: FWIW I agree that Talos results for Linux32 are unimportant. Even if there was a Linux-32-only regression, I don't think it'd be worth our developers spending time on it. I agree. Kill them. https://www.youtube.com/watch?v=5DckrYRSsUA Justin

Re: [stats] Counting HTTP/2 domain names

On 9/10/15 4:55 AM, Patrick McManus wrote: no - generally we don't do origin based telemetry for privacy reasons I suppose, if one really wanted to, that this could be approximated on the client side... Have the browser track all the HTTP/2 domains it connects with, and only report the total

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

On 7/7/15 6:17 PM, David Anderson wrote: +1 for removing this. Gecko's use is inconsistent, and outside of Gecko code that does use it, I've never seen it used in any other codebase. I've never gone to another project and thought, I miss decorating everything in a way that changes capitalization

Re: Voting in BMO

On 6/9/15 2:24 PM, Chris Peterson wrote: I vote for bugs as a polite (sneaky?) way to watch a bug's bugmail without spamming all the other CCs by adding myself to the bug's real CC list. I think if Bugzilla, with its long and complex history, ever has a hope of being untangled into something

Re: Voting in BMO

On 6/9/15 7:09 PM, Ehsan Akhgari wrote: I cannot remember a single instance where I or someone who I know has used the number of votes on a bug as an input for making a decision, and that is for good reason, since the number of votes tell you nothing about how severe a problem actually is, and

Re: Intent to implement and ship: document.execCommand(cut/copy)

On 5/6/15 10:02 AM, Ehsan Akhgari wrote: 1. The scenario that you're describing is already possible on the Web, through Flash. However, I have not seen any evidence of this kind of thing ever occurring in the wild. Given the fact that people have literally had years to start trying to do

Re: Excessive inbound bustage

On 4/21/15 5:26 PM, Mike Hommey wrote: ... - the biggest backout rate for those authors is 48.8%. The suspense is killing me. Is it Ehsan?! ;-) ;-) Justin ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

On 4/14/15 8:40 AM, Dave Townsend wrote: I've gotten used to just ignoring these fields and reading the bugs instead. I wouldn't feel any loss if they were just removed from display entirely. +1. The fields are broadly unreliable, and we should just remove them. I think I've seen the

Re: Bug 706103 should be backed out. Theme authors very unhappy

On 4/3/15 5:53 AM, Philip Chee wrote: Really? Nobody can reopen a bug except the owner? [thinks some more] actually this might come in handy. If some idiot tries to reopen one of my bugs, I can always slap them down and tell them this is Mozilla policy. I'd instead say that the people

Re: Intent to deprecate: persistent permissions over HTTP

It does seem to me that popup-blocking isn't a great fit for this list. AIUI this started from Chrome's intent to start moving powerful features to SSL-only (with this being a first step), and allowing popups doesn't seem like that kind of feature. It's also worth noting that our popup blocker is

Re: Permission UI

I don't actually think about:permissions is a good start, or that it's implemented most of the complicated bits. Quite the opposite, really: it was a useful experiment, but has some serious problems. I'd briefly summarize the two main flaws as (1) manager UIs are generally not great (they provide

Re: Tree Status Addon

On 2/4/15 6:52 PM, Giovanny Gongora wrote: What is the minimum Firefox version? Because I am using 33 and it says on AMO that is not available for my Firefox version. The correct answer here is that Firefox 33 is unsupported and insecure. You should either upgrade to Firefox 35 (the current

Re: Migrating defaults from other browsers

On 1/19/15 4:58 AM, Henri Sivonen wrote: I think this leads to a more general question: Is it really a good idea that our profile migrators migrate settings from other browsers when those settings have been left to the defaults of those browsers? My assumption was that we're only migrating

Re: W3C Proposed Recommendation: longdesc

On 1/6/15 6:37 PM, Jet Villegas wrote: The main downside I see is a potential Mozilla removes features used by disabled people... PR fiasco. I think we can avoid that with a better proposal that we do support. I'd be really curious to see if this is actually being used by anyone. We're

Re: e10s is now enabled by default for Nightly!

On 11/8/14 1:03 PM, Nicholas Nethercote wrote: On Sun, Nov 9, 2014 at 12:29 AM, jmath...@mozilla.com wrote: Everyone should start familiarizing themselves with the idiosyncrasies of debugging three processes at once, it'll be the norm this spring. Three? I've only seen two... Chrome,

Windows 10 package manager

http://www.extremetech.com/computing/192950-windows-10-will-come-with-a-command-line-package-manager-much-to-the-lament-of-linux-users With Windows 10, however, we are finally getting an official package manager: OneGet. In the current build of Windows 10 Technical Preview, you can open up

Re: The worst piece of Mozilla code

On 10/16/14 5:32 AM, Nicholas Nethercote wrote: I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll leave the exact meanings of worst and piece of code unspecified... It's gone now, but I always held a special hate for nsIDialogParamBlock.

Re: Breakdown of Firefox full installer

On 10/14/14 2:20 AM, Robert Strong wrote: * (Countries' average) Internet speed dramatically affected conversion rates: 70% success in the fastest countries and 30% in the slowest countries. Note that these conversion rates are from download to hitting the first run page and there are several

Re: Deprecate geolocation and getUserMedia() for unauthenticated origins

On 10/2/14 1:07 PM, Martin Thomson wrote: On 02/10/14 11:58, Ehsan Akhgari wrote: What data specifically? I'm fairly confident that we can make this change no matter how many websites use geolocation from non-authenticated origins. I believe that usual practice before we remove something we

Re: Intent to implement: image-rendering: pixelated CSS property-value

On 9/23/14 4:24 PM, Jonas Sicking wrote: This makes the implementation considerably simpler, which is great. It also means that pixelated will essentially just be a more-interoperable version of -moz-crisp-edges, for the time being. Would it make sense to have separate properties for scale

Re: Restricting gUM to authenticated origins only

On 9/10/14 2:09 AM, Henri Sivonen wrote: Chrome auto-decides whether the grant is persistent based on whether the URL is http or https. Whoa. That's non-obvious and creepy. As a user, I find it creepy for an UI that looks like a one-time grant to actually do a persistent grant. Indeed. I

Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?

On 8/26/14 6:43 AM, Patrick McManus wrote: I think it would make a lot of sense to have an explicit low bandwidth mode that did stuff like this, instead of trying to address it piecemeal. There's all kinds of stuff that can consume bandwidth, and if we think it's a real concern then let's

Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?

On 8/22/14 10:17 AM, Hubert Figuière wrote: On 21/08/14 01:29 PM, Wesley Johnston wrote: Summary: We've had some complaints at times about videos autoplaying on mobile devices when sites request autoplay. [...] Autoplay waste bandwidth, whether mobile or wifi. In some case it is more serious

Re: Rethinking the crash experience

On 7/7/14 12:21 PM, Ehsan Akhgari wrote: We should keep in mind that sometimes due to startup crashes, we don't get to run any of the code in Firefox, so we can't gate the crash report submission on that code at least in the case of startup crashes. Yes. For that, I think we'll need to retain

Re: Rethinking the crash experience

On 7/8/14 9:56 AM, Tobias Besemer wrote: Am Dienstag, 8. Juli 2014 18:23:00 UTC+2 schrieb Justin Dolske: 2) Being able to integrate the crash-submission flow into the browser opens up possibilities for better UX and features, since it's the familiar cross-platform environment we all work

Re: Intent to ship: Hyperlink Auditing (a ping)

On 5/16/14, 6:38 AM, Curtis Koenig wrote: Would this be disabled in Private Browsing? If not that might be perceived as negating one of the reasons users have for using that particular feature. Private Browsing mode is about not storing _local_ data from your activities. It is explicitly not

Re: Memory management in features implemented in JS

On 3/19/14 4:39 PM, Kyle Huey wrote: We are discovering a lot of leaks in JS implemented DOM objects. The general pattern seems to be that we have a DOM object that also needs to listen to events from the message manager or notifications from the observer service, which usually hold strong

Re: Always brace your ifs

On 2/22/14 7:18 AM, Kyle Huey wrote: If you needed another reason to follow the style guide: https://www.imperialviolet.org/2014/02/22/applebug.html I don't really disagree with bracing being a good idea, but I'll be contrarian here. Mandatory bracing probably wouldn't have helped; since you

Re: ISomething, nsISomething or mozISomething?

On 2/17/14 12:41 PM, Ehsan Akhgari wrote: On 2/17/2014, 9:15 AM, David Rajchenbach-Teller wrote: Do we have naming conventions for new xpcom interfaces? I believe that I have seen all three forms on the tree. I need to pick one for my new bug. Which one should I pick? Avoid ISomething since

Re: What platform features can we kill?

On 10/9/13 11:29 AM, Boris Zbarsky wrote: RDF We use RDF in Firefox, in localstore.rdf among others I guess. Right. We should stop doing that. ;) Bug 559505 - localstore.rdf kills ponies I got hung up on the (ancient) patch there because RDF is baked pretty firmly into the XUL Tree

Re: Audit your code if you use mozilla::WeakPtr

On 10/8/13 6:04 PM, Ehsan Akhgari wrote: This code pattern is another problem -- you need to keep object alive if you want to do this some other way. We have an idiom for this kind of thing in fact (grep for kungFuDeathGrip!) Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.)

Re: Poll: What do you need in MXR/DXR?

On 10/2/13 12:33 PM, Erik Rose wrote: What keeps you off DXR? (What are the MXR things you use constantly? Or the things which are seldom-used but vital?) First -- this work is really awesome. DXR already feels like it's close to being something I can switch over to. If for no other reason

Re: JavaScript Style Guide. Emacs mode line.

On 9/10/13 3:09 AM, ishikawa wrote: OTOH, code in a strange indentation is hard to touch: during linux development around 2.1.1xx, Alan Cox got tired of the spaghetti code of SCSI driver subsystem and introduced a revision: that revision consisted only of sweeping reformatting of scsi

Re: Viewing resource usage of builds

On 8/23/13 1:16 PM, Ehsan Akhgari wrote: Finally, this is just a friendly reminder that if you build mozilla-central and you don't have a machine with at least 4 *physical* cores, 16 GB RAM, and an SSD, you should upgrade your hardware. FTR, my Windows machine has 16GB of ram, 4 physical

Re: Code Review Session

On 5/28/13 7:39 AM, Benjamin Smedberg wrote: Bugzilla is our tracking tool of record. I'm personally rather bullish about bugzilla improvements, now that the 4.2 upgrade is done and we have solid people working on it and making weekly improvements. Yeah. It has its share of flaws, but it's

Re: Proposal to make Firefox open in the foreground on Mac when launched from terminal

On 5/29/13 3:09 PM, Ehsan Akhgari wrote: Typically when you use the terminal to open an application on Mac, the application is opened in the background. Mmm, indeed. Someone told me long ago this this was a platform convention, but it sure is annoying. Seems like a nice refinement to me.

Re: Geolocation and the Mac

On 5/21/13 4:45 PM, Doug Turner wrote: The main difference is that you will get one prompt from the OS the first time you use geolocation from Firefox -- just like every other standard Mac application. Could be a little odd, but as long as it comes up after our own permission dialog it

Re: Geolocation and the Mac

On 5/22/13 9:49 AM, Doug Turner wrote: The Mac has a system where by location services for all apps are managed in a central place. We do not work in that system -- we do something different. This makes a user's view of how their location information is being share not complete. :( And we

Re: Proposal for an inbound2 branch

On 5/1/13 8:41 PM, Ehsan Akhgari wrote: Another disadvantage of project branches in addition to the ones mentioned before is that it limits/delays the amount of testing that you can get on Nightly and from all of the developers who run things like fuzzers on ours code. Not everyone's project

Re: Storage in Gecko

On 4/26/13 11:17 AM, Gregory Szorc wrote: But, please don't make consumers worry about things like SQL, schema design, and PRAGMA statements. Ideally, yes. But I suspect there will never be a one-size-fits all solution, and so we should probably be clear about what it's appropriate/intended

Re: Rethinking the amount of system JS we use in Gecko on B2G

On 4/21/13 4:51 PM, Justin Lebar wrote: What I'd like to come out of this thread is a consensus one way or another as to whether we continue along our current path of writing many features that are enabled on B2G in JS, or whether we change course. First -- B2G should clearly do whatever it

Re: Revamping touch input on Windows

On 4/18/13 5:50 AM, Jim Mathies wrote: One of the concerns here is that since we do not differentiate the metro and desktop browsers via UA, the two should emulate each other closely. The browser would appear completely broken to content if the same UA sent two different event streams. So we

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

On 4/10/13 1:53 PM, Alex Keybl wrote: Knowing this, why not consider just using the status-flags purely to track landings and let the team determine how to use target milestone? Also, why not set the status-flag in general for the appropriate Firefox release when a patch lands on trunk? The

Re: proposal: replace talos with inline tests

On 3/4/13 9:36 AM, Gregory Szorc wrote: If all your tests are declared the same way, then presumably the test running code would be similar and capturing performance data would require a single implementation affecting all test suites instead of N 1-off solutions. We've talked about this

Re: Proposed W3C Charter: HTML Working Group

On 2/8/13 2:37 PM, L. David Baron wrote: W3C is proposing a revised charter for the HTML Working Group. For more details, see: http://lists.w3.org/Archives/Public/public-new-work/2013Feb/0009.html http://www.w3.org/html/wg/charter/2012/ Is there a way to see what's changing from the current

Re: Question about Bugzilla bug dependencies

On 1/7/13 1:02 PM, 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 fixed until regression Y is fixed) or should Y depend on X (because regression Y does

Re: Use of instanceof SomeDOMInterface in chrome and extensions

On 12/27/12 11:20 PM, Boris Zbarsky wrote: On 12/27/12 2:49 PM, Justin Dolske wrote: Hmm. My first reaction is to gently challenge if this really has to change Well, it really has to change as exposed to web content (or we have to convince every single other browser to change behavior and get

Re: Use of instanceof SomeDOMInterface in chrome and extensions

On 12/27/12 2:18 AM, Boris Zbarsky wrote: The arguably right way to do the el instanceof HTMLAnchorElement test is: el instanceof el.ownerDocument.defaultView.HTMLAnchorElement Needless to say this sucks. Eew, indeed. So the question is how we should make the above work sanely. [...]

  1   2   >