Re: Intent to Unship: Fake Plugins

oving fake plugins for now was fine, and once work on that was active, we can revisit and possibly revive parts as needed. On Thu, Feb 21, 2019 at 1:55 PM Boris Zbarsky wrote: > On 2/21/19 3:44 PM, Kyle Machulis wrote: > > and Pdf.js is still shipping as a stream handler for the >

Intent to Unship: Fake Plugins

Metabug: https://bugzilla.mozilla.org/show_bug.cgi?id=1529133 Fake plugins are JS plugins that render as a document instead of a plugin, but still live in the general area of plugins (loading through object/embed elements in nsObjectLoadingContent, having plugin tags, etc). They were original

Re: XPCOM Tidying Proposal

On Mon, Jan 14, 2019 at 9:12 AM Bobby Holley wrote: > > I think the answer is "it depends". BasePrincipal makes a lot of sense for > principals, because it allows for a lot of sharing among the subclasses, of > which there are only four. URIs are more complicated, and probably deserve > a

Re: XPCOM Tidying Proposal

On Fri, Jan 11, 2019 at 11:59 AM Bobby Holley wrote: > The idea is that we should gradually pass BasePrincipal around the codebase > rather than nsIPrincipal, which would avoid the need to invoke Cast at the > specific callsite. I have no objection to your proposed pattern in the > interim if it

Re: XPCOM Tidying Proposal

On Fri, Jan 11, 2019 at 7:21 AM Nathan Froyd wrote: > > - Removal of [noscript] methods in interfaces in favor of direct calls > via > > Cast() where possible. > > - Direct getters through Cast() where possible, infallible (also where > > possible) otherwise. > > For avoidance of doubt, since I

XPCOM Tidying Proposal

In an effort to bring Marie Kondo memes to dev-platform, I'd like to propose an XPCOM tidying project. Through DeCOMtamination, Quantum, Fission, and other projects, we've managed to un-hide quite a few headers to C++ classes that would've otherwise been only accessible through XPCOM interfaces,

New CEnum enumeration type in XPIDL

Since just about forever (no, really: https://bugzilla.mozilla.org/show_bug.cgi?id=8781), there's not really been an enum type in XPIDL. This means that we have a lot of interfaces with lots of similarly named consts, that are usually passed around in C++ as uint32_t's, though sometimes we

Bypassing about:home/privacy page loads on new test profile builds via mach

I've got some gecko checkouts set in debug mode that I often have to rebuild, meaning their test profile may be removed/regenerated at times. Bringing up a new firefox profile with the default about:home and privacy warnings can take a while. Thanks to some help from nalexander in #build, I've

Re: Proposal: WebIDL generated bindings classes renamed from dom::FooBinding to dom::binding::Foo

+1 on the namespace idea. We started using mozilla::dom::FooBinding::[ConstantName] namespace for constants in bug 792059, so we may also want to change that to dom::binding::Foo::[ConstantName] for consistency sake. On Thu, Jun 7, 2018 at 1:03 PM, Jeff Gilbert wrote: > We have a name conflict

Re: Proposed W3C Charter: Devices and Sensors Working Group

Filling in some of the gaps here: WakeLock API is still used on android, afaik so we don't let the phone turn off while playing media. We ship the Vibration API on android, have since FxOS. Not much happening there these days, other than some discussion about permissions around it. We still

Re: skip-if(verify)

In my experience, many tests were written pre-test-verify, and don't clean up correctly to deal with multiple runs in the same process. They work fine when running as a single session, but blow up in TV. Having skip-if(verify) means that we can at least mark those tests as known broken on TV

Intent to (start) Ship(ping) (sorta): WebMIDI

After a few years of development as I've had time, the first portion of WebMIDI (bug 1201590), the web standard API for accessing MIDI-enabled hardware (this is not related to MIDI files or playback), should be landing soon. This bug only includes the core DOM API code and tests, with no actual

Re: Device Orientation API future

I took over the DOM: Device Interfaces component last month, and as part of that was looking at the Generic Sensor APIs (and have been following this conversation too). I've read over the spec, but that's about it so far. While we've had a couple of outside questions about implementation, it

WebIDL consts now generate C++ definitions

As of Bug 792059 landing, If you're adding new WebIDL interfaces to gecko, we will now generate constant definitions in the binding namespace of the C++ binding headers. For example, if you have a WebIDL interface that looks like --- interface TestExampleInterface { ... [NeedsWindowsUndef]

Re: More Rust code

So, I've been kinda working toward the "more rust in gecko" goal, in my own space that just happened to be a good sandbox for it. Last year I was brought over to help on WebAuthn, which needs access to USB HID for things like Yubikeys. I decided to write the lowest level cross platform parts of

Re: Please write good commit messages before asking for code review

This has actually been confusing me in reviews, since the commit-message looks like another file in the diff. Not sure of a better way to show this isn't going to be a file when checked in, but with the way it's shown as part of the change set in the patch right now, it's hard to discern. On Thu,

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

In bug 781982, we're planning on implementing IndexedDB capabilities in Private Browsing Mode. The current plan is to: - Store IDB databases, minus blobs, in memory for the lifetime of the private browsing session - Store blobs to disk, encrypted via a key that is only held in memory during the

Fixing mach error colorization in emacs compilation buffers

Pass-thru of ANSI color codes for compilation warnings/errors was recently added to mach. If emacs users don't have ansi-mode turned on for compilation buffers, they'll now see raw ANSI codes, which makes reading errors difficult. To turn on ansi-mode for compilation buffers, add the following

Editor/IDE Configuration Page on MDN

Last week I ended up dealing with some headaches between emacs packages and gecko development. To make sure no one else had to waste time on it, I've created an "Editor Configuration" page on MDN to document steps for making gecko development faster/easier on whatever your editor of choice might

Re: emacs M-x gdb and mach --debug

In the interest of expanding this beyond just the -i=mi stuff, I've created a metabug for making mach and emacs play nicer together: https://bugzilla.mozilla.org/show_bug.cgi?id=1263253 If you've got any wants for things emacs could do but doesn't that would make life developing gecko/ff/sm/etc

Re: emacs M-x gdb and mach --debug

https://bugzilla.mozilla.org/show_bug.cgi?id=1254313 I've had this filed for a while now, just need to do something about it. :/ On Fri, Apr 8, 2016 at 9:13 AM, Andreas Farre wrote: > Looking for someone emacs savvy to help me with running mach --debug as a > command for

Intent to Implement/Ship: document.elementsFromPoint

*Summary*: We don't currently support documents.elementsFromPoint, while IE and Chrome do (I'm not sure if Opera and Safari have gotten around to it yet). It's making important things like IRCCloud angry. There's also an elementsFromRect, but I think I may wait on that since it doesn't even have a

LGPL external library support in gecko

As of bug 1176300 landing (and hopefully sticking), we now have a place for LGPL symbols in gecko. There's a new shared library called lgpllibs (because I am horrible at naming things but it should at least be obvious what it is). Currently it holds libsoundtouch, which is LGPL with exception, but

Intent to Implement: User Timing API

Summary: We've already got the performance resource timing API implemented (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got around to implementing the user timing API. This would allow users to set unique marks for profiling events in their own code, and most of the objects

Re: Intent to Implement: User Timing API

Yup, this is all Eli's fault. :) - Original Message - From: Ehsan Akhgari ehsan.akhg...@gmail.com To: Kyle Machulis kmachu...@mozilla.com, dev-platform@lists.mozilla.org, dev-web...@lists.mozilla.org, Eli Perelman eperel...@mozilla.com Sent: Thursday, December 11, 2014 5:57:44 PM

The future of HAL vs DOM for device APIs?

I'm working on Gamepad OOP (bug 852944). We want to have an actor-per-device-per-process model for IPC. Right now, Gamepad's platform specifics live in HAL, as it's just using the observer broadcast model. Moving to the new actor model, it doesn't feel like gamepad will really fit in HAL

Re: Intent to implement: WebMIDI

MIDI isn't just USB, though. It's a protocol that can happen over many modes of transport; some of the stage systems I mentioned use ethernet, or there's still tons of hardware with actual MIDI ports (I have 2 IN/OUTs via my DAC connected to the machine I'm typing this from, for instance). We

Re: Intent to implement: WebMIDI

Well, it's mostly going to be happening in my spare time. I'm working alongside the Google team on it (have already met with them a couple of times), as well as keeping in touch with potential users. So hopefully the only requirements for resources will be reviews. Everything from HAL to DOM

Re: We live in a memory-constrained world

In valgrind on FxOS devices (right now only nexus 4/5), we run checks against IPC. Unfortunately there's no automation there at the moment. We've got a goal to get IPC turned on for b2g desktop ASAP though, at which point we might be able to look at that. - Original Message - From: