Intent to unship: -moz-placeholder pseudo-element and pseudo-class

I intend to remove "-moz-placeholder" pseudo-element and pseudo-class in bug 1300896. We already supported canonical version of them: 1. "::placeholder" in bug 1069012, FF 51. 2. ":placeholder-shown" in bug 1069015, FF 51. To support these mozilla-specific aliases introduces special-case

Re: Intent to unship: xml:base attribute

On Wed, May 24, 2017, at 11:30 AM, Jet Villegas wrote: > xml:base (bug 1349024) has been removed in Nightly 55 for 2 months > now, and we haven't sen any reports of ill effects. Let's have this > testing expand to Beta 55, and on to Release if all goes well. Bug > 1350521 tracks this change riding

Re: Intent to unship: xml:base attribute

xml:base (bug 1349024) has been removed in Nightly 55 for 2 months now, and we haven't sen any reports of ill effects. Let's have this testing expand to Beta 55, and on to Release if all goes well. Bug 1350521 tracks this change riding the trains. --Jet On Thu, Feb 16, 2017 at 2:51 PM, Xidorn

Re: Start logging at runtime (Firefox 52)

You're going to have a pretty bad day if you route the rather verbose http logs through the browser console. In general I think it's feasible, we could probably add a pref for it and just punt messages to the console service instead of fprintf_stderr. We have a bug filed for working around the

Re: Start logging at runtime (Firefox 52)

On Wednesday, May 24, 2017 at 2:22:49 AM UTC+12, Valentin Gosu wrote: > I think the you can get around the issue by setting the > security.sandbox.content.level pref to 0 while you're debugging. > > On 23 May 2017 at 08:32, Shih-Chiang Chien wrote: > > > Which platform

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: Status of support for Android on ARMv7 without NEON

Yes, the store doesn't provide any filtering for non-neon armv7 devices. We were going to write some runtime test+error page, but it looks like that didn't happen. Sorry for the hassle, -r On Tue, May 23, 2017 at 1:00 PM, wrote: > I was updating from Google Play without

Re: Status of support for Android on ARMv7 without NEON

I was updating from Google Play without any warning on my -indeed very old but good functioning- ASUStransformer tf101. Took even a while to figure out what the problem was and why all of a sudden FF didn't work anymore. PtrK ___ dev-platform mailing

Re: Scope of XML parser rewrite?

I was hoping to write a more thorough blog post about this proposal (I have some notes in a gist [1]), but for now I've added comments inline. The main takeaway here is that I want to do a bare-bones replacement of just the parts of expat we currently use. It needs to support DTD entities, have a

Re: Mozilla Charset Detectors

On 5/23/17 2:58 AM, Gabriel Sandor wrote: Hello Henri, I was afraid this might be the case, so the library really is deprecated. The project i'm working on implies multi-lingual environment, users, and files, so yes, having a good encoding detector is important. Thanks for the alternate

Re: Improving visibility of compiler warnings

I had it pointed out to me on IRC by jcristau that `chronic` already exists as a Unix utility from moreutils: https://manpages.debian.org/jessie/moreutils/chronic.1.en.html It does pretty much the exact same thing as nowarn, but is probably better written ^.^. On Tue, May 23, 2017 at 11:56 AM,

Re: Improving visibility of compiler warnings

I don't have enough time to work on a proper solution, but I wrote a simple rust wrapper which just consumes stderr from the wrapped process, and doesn't write it out unless the internal command exited with a non-zero exit code. I figured I'd post it in case anyone else finds it useful.

Re: Scope of XML parser rewrite?

Am 23.05.17 um 16:01 schrieb Daniel Fath: So, if I understand this correctly - We'll first need to land this component in Firefox, right? And if it proves itself fine, then formalize it. I was thinking of having resolutions for the issues that are currently warnings in red and multi-vendor

Re: Start logging at runtime (Firefox 52)

I think the you can get around the issue by setting the security.sandbox.content.level pref to 0 while you're debugging. On 23 May 2017 at 08:32, Shih-Chiang Chien wrote: > Which platform you're using? For windows it seems to be solved by >

Re: Scope of XML parser rewrite?

So, if I understand this correctly - We'll first need to land this component in Firefox, right? And if it proves itself fine, then formalize it. > I was thinking of having resolutions for the issues that are currently > warnings in red and multi-vendor buy-in. (Previously, Tab from Google > was

Re: Mozilla Charset Detectors

Hello Henri, I was afraid this might be the case, so the library really is deprecated. The project i'm working on implies multi-lingual environment, users, and files, so yes, having a good encoding detector is important. Thanks for the alternate recommendations, i see that they are C/C++

Re: Scope of XML parser rewrite?

On Tue, May 23, 2017 at 12:44 PM, Daniel Fath wrote: >> (If the outcome here is to do XML5, we should make sure the spec is >> polished enough at the WHATWG in order not to a unilateral thing in >> relative secret.) > > What does it mean to be polished enough at the

Re: Scope of XML parser rewrite?

> (If the outcome here is to do XML5, we should make sure the spec is > polished enough at the WHATWG in order not to a unilateral thing in > relative secret.) What does it mean to be polished enough at the WHATWG? Also how far reaching should spec be? Include Namespaces? On Tue, May 23, 2017

Re: Scope of XML parser rewrite?

Figured out the email address of the XML5 editor / xml5ever developer, so adding to CC. On Tue, May 23, 2017 at 9:43 AM, Henri Sivonen wrote: > In reference to: https://twitter.com/nnethercote/status/866792097101238272 > > Is the rewrite meant to replace expat only or also

Scope of XML parser rewrite?

In reference to: https://twitter.com/nnethercote/status/866792097101238272 Is the rewrite meant to replace expat only or also some of our old code on both above and below expat? Back in 2011, I wrote a plan for rewriting the code around expat without rewriting expat itself:

Re: Start logging at runtime (Firefox 52)

Which platform you're using? For windows it seems to be solved by https://bugzilla.mozilla.org/show_bug.cgi?id=1320458, however other platforms are not fixed yet. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Tue, May 23, 2017 at 11:59 AM, Chris Pearce wrote: > On