Re: Intent to Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis wrote: > AFAIK, Chrome's strategy for this is to just store everything in memory and > keep a fairly small size cap on it (something like 32mb?). > Really? Last I asked they said they basically created a new temporary

Re: Disabling non-Skia builds

I'm 100% in support of this. One thing I'd like to know though is how we're going to deal with upstreaming patches to Skia on behalf of third parties? In my experience, it's rarely been a case of simply submitting a patch and having it accepted; there's normally a decent amount of engineering

Re: Disabling non-Skia builds

Right. Good point to clarify. We're not taking on the ownership of the patches that need to go upstream, and my original wording could be interpreted that way. So, we can forward the patches to Skia, for example, but we'd be forwarding the whole conversation, that the patch author would

Expanding regular regression triage to include crashes?

Hi, Currently there are two platform regression triage meetings per week during which bugs marked with the "regression" keyword are triaged. See https://wiki.mozilla.org/Platform/ for details. Last week Jim Mathies and I discussed the possibility of expanding the triage to include bugs marked

HTML email enabled by default on bugzilla.mozilla.org

Earlier today, the BMO Team enabled HTML email by default on bugzilla.mozilla.org. BMO has had support for HTML email content for a long time now and originally we had it off by default in order to work out any remaining issues still lingering with proper display of bug changes, etc. We have not

Intent to ship: CSS Mask Image

After bug 1251161 landed, we turned CSS mask image on by default on all platforms. It has been developed behind the MOZ_ENABLE_MASK_AS_SHORTHAND compile flag. Chrome is already shipping this in version 29. (Original plan is to turn it on by FF 50, delay it to FF 53 is because of some performance

Re: Expanding regular regression triage to include crashes?

+1 on expanding the search. That should help get earlier diagnosis. We should also add 'regression' to those bugs as part of triage, as appropriate. --Jet On Wed, Dec 14, 2016 at 6:11 PM, Nicholas Nethercote wrote: > Hi, > > Currently there are two platform regression

Re: Expanding regular regression triage to include crashes?

On Thu, Dec 15, 2016 at 2:17 PM, Ryan VanderMeulen wrote: > > I like the idea in principle, but in practice, two meetings a week is already not enough to get through regression bugs. Are we going to add more meetings to accommodate this? And I'll note that already, attendance of

Ensuring new CSS features are supported in Quantum CSS

Hi, For the Quantum CSS project, we are aiming not to regress support for CSS features when the Servo-backed style system is turned on. This means that if you are implementing a new CSS feature that will land (behind a pref or not) before Quantum CSS is ready to ship, we'll need to do some work

Re: Expanding regular regression triage to include crashes?

I like the idea in principle, but in practice, two meetings a week is already not enough to get through regression bugs. Are we going to add more meetings to accommodate this? And I'll note that already, attendance of the regular regression triage meetings has declined from where it was a

Re: Intent to Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

This is great Kyle. Historically this has been one of the biggest requests that we've had from developers with regards to private browsing. I'm happy that we're finally addressing this use case. On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis wrote: > In bug 781982,

Re: Intent to Implement: Private Browsing Storage (IndexedDB, Blobs, etc)

On Wed, Dec 14, 2016 at 9:35 AM, Ben Kelly wrote: > On Tue, Dec 13, 2016 at 7:35 PM, Kyle Machulis > wrote: > > > AFAIK, Chrome's strategy for this is to just store everything in memory > and > > keep a fairly small size cap on it (something like