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 handling
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
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 Qua
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 roo
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 you're using? For windows
(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 last
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 any warning on my -inde
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 l
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
s
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 recomme
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, M
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.
https://git
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 buy-
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
> https://bugzilla.mozilla.org/show_bug.cgi?id=1320458, h
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 in
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++ librarie
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 WHATWG?
I was thinking of havi
> (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 at
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 some of our old
> code
19 matches
Mail list logo
