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 handling
in both stylo and gecko, which bring in unnecessary complexity.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: xml:base attribute

[Xidorn Quan]

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 the trains.

To be accurate, xml:base isn't removed (because the telemetry number
doesn't look quite good). Instead, we are making xml:base no longer
affect style attribute. And this is what has been done, and what we want
to expand the testing for.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: xml:base attribute

[Jet Villegas]

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 Quan  wrote:
> Tracking bug: https://bugzilla.mozilla.org/show_bug.cgi?id=903372
>
> Summary:
> * It has been removed from the spec years ago.
> * No other browser supports it.
> * We pay performance penalty for it.
> * It makes things trickier for stylo to handle URL values.
>
> The tricky thing is that nsParserUtils::ParseFragment currently relies
> on xml:base. That is going to be fixed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1313278
>
> Are there any objections?
>
> - Xidorn
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Start logging at runtime (Firefox 52)

[Eric Rahm]

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 root cause,
https://bugzilla.mozilla.org/show_bug.cgi?id=1345046 for a more robust
solution, but that doesn't currently have an owner.


On Tue, May 23, 2017 at 4:32 PM, Chris Pearce  wrote:

> 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 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 Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu
> wrote:
> > > > > Hi everyone,
> > > > >
> > > > > (I meant to send this mail a few weeks ago but forgot it in my
> Drafts
> > > > > folder.)
> > > > >
> > > > > With the landing of Bug 1303762 (Firefox 52), we now have a way for
> > > users
> > > > > to enable logging without restarting the browser, and without
> having to
> > > > > know what an environment variable is.
> > > > >
> > > > > We've added a new Logging section to about:networking. When a user
> > > > > encounters a bug, all they have to do is open that page, click on
> > > "Start
> > > > > Logging", reproduce the bug, then click on "Stop Logging" and
> upload
> > > the
> > > > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG
> env
> > > > > variables have been defined.
> > > > > The log modules are automatically set to the most common networking
> > > > > modules, but you may instruct the bug reporters to change them -
> just
> > > > tell
> > > > > them the string.
> > > > >
> > > > > This is very useful for bugs that are harder to reproduce once you
> > > > restart
> > > > > the browser.
> > > > >
> > > > > There are a bunch of improvements that we could make to the UI, so
> > > please
> > > > > feel free to send me your feedback and patches. Many thanks to
> Honza
> > > > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> > > helped
> > > > > with the implementation and review of this bug and its
> dependencies.
> > > > >
> > > > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > > > HTTP_logging?document_saved=true#Using_aboutnetworking
> > > >
> > > > This seems super handy, but I tried it out and it seems to only
> affect
> > > the
> > > > parent process, and not the sub-processes of Firefox?
> > > >
> > > > ___
> > > > dev-platform mailing list
> > > > dev-platform@lists.mozilla.org
> > > > https://lists.mozilla.org/listinfo/dev-platform
> > > >
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
>
> I'm using Firefox 54b10 32bit on Windows 10 x64.
>
> Changing the sandbox pref worked, though it required a restart.
>
> Has anyone thought of routing MOZ_LOGs to the Browser Console? How hard
> would that be?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Start logging at runtime (Firefox 52)

[Chris Pearce]

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 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 Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> > > > Hi everyone,
> > > >
> > > > (I meant to send this mail a few weeks ago but forgot it in my Drafts
> > > > folder.)
> > > >
> > > > With the landing of Bug 1303762 (Firefox 52), we now have a way for
> > users
> > > > to enable logging without restarting the browser, and without having to
> > > > know what an environment variable is.
> > > >
> > > > We've added a new Logging section to about:networking. When a user
> > > > encounters a bug, all they have to do is open that page, click on
> > "Start
> > > > Logging", reproduce the bug, then click on "Stop Logging" and upload
> > the
> > > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > > > variables have been defined.
> > > > The log modules are automatically set to the most common networking
> > > > modules, but you may instruct the bug reporters to change them - just
> > > tell
> > > > them the string.
> > > >
> > > > This is very useful for bugs that are harder to reproduce once you
> > > restart
> > > > the browser.
> > > >
> > > > There are a bunch of improvements that we could make to the UI, so
> > please
> > > > feel free to send me your feedback and patches. Many thanks to Honza
> > > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> > helped
> > > > with the implementation and review of this bug and its dependencies.
> > > >
> > > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > > HTTP_logging?document_saved=true#Using_aboutnetworking
> > >
> > > This seems super handy, but I tried it out and it seems to only affect
> > the
> > > parent process, and not the sub-processes of Firefox?
> > >
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >

I'm using Firefox 54b10 32bit on Windows 10 x64.

Changing the sandbox pref worked, though it required a restart.

Has anyone thought of routing MOZ_LOGs to the Browser Console? How hard would 
that be?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Photon Engineering Newsletter #2

[Justin Dolske]

(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
week’s update, the team has largely shifted from the planning to
implementation, so visible changes are starting to come quickly.
Work Week

A particularly big event was the Photon team gathering in Mozilla’s Toronto
office for a work week. About 50 people from Engineering, UX, User
Research, and Program Management gathered, from all over the world, with a
focus on building Photon. Mozilla operates really well with
distributed/remote teams, but periodically getting together to do things
face-to-face is super useful to work through issues more quickly.

[image: photonww_shorlander_small]

It was really terrific to see so many people coming together to hack on
Photon. We got a lot done (more on that below), saw some great demos, and
the energy was high. And of course, no workweek is complete
 without UX creating
some fun posters:

[image: 57small]

One important milestone reached during the week was setting the initial
scope for what’s going to be included in Photon (or, more bluntly, what’s
NOT going to be part of Photon when it ships in Firefox 57). We’re still
refining estimates, but it looks like all the major worked planned for
Photon can be accomplished. Most things placed in the “reserve backlog”
(meaning we’ll do it if there’s extra time left, but we’re not committing
to do them) are minor or nice-to-have things.

This is probably a good spot to talk a little more about our schedule
. Firefox 57 is the release
that Quantum and Photon are targeting. It’s scheduled to ship on November
14th, but there are important milestones before then… September 22nd is
when 57 enters Beta, after that point it’s increasingly hard to make
changes (because we don’t want to destabilize Firefox right before it
ships). August 7th is when Nightly becomes version 57. This is also our
target date to be complete with “major work” for Photon. This might seem a
little surprising, but it’s due to the recent process change

that removed Aurora. Under the old release schedule, August 7th is when
Nightly-57 uplifted to Aurora (beginning ~12 weeks of stabilization before
release). We want to keep the same amount of stabilization time (for a
project as big as Photon there is _always_ fallout and followup work), so
we kept the same calendar date for Photon’s target. This doesn’t mean we’ll
be “done” on August 7th, just that the focus will be shifting from
implementing features to fixing bugs, improving quality, and final polish.

And now for the part you’ve all been waiting for, the recent changes!
Recent Changes

Menus/structure:

   - The page action menu (aka the “…” button at the end of the URL bar)
   got the first menu items added to it
   , Copy URL and
   Email Link. More coming, as this becomes the standard place for “actions
   you can perform with this page” items.
   [image: actionmenu_first]
   - The new hamburger menu is coming along, although still disabled by
   default (via the browser.photon.structure.enabled pref). Items for
   character encoding, work offline, and the devtools submenu have been added
   to it.
   - The new overflow menu (also disabled by default, same pref) is nearing
   completion with 2/3 of the bugs fixed. This menu is now shown in customize
   mode (instead of the old hamburger menu); so instead of only showing icons
   that couldn’t fit in the navbar (e.g. because you made your window too
   narrow), it’s the new place you can customize with buttons you want to be
   easily accessible without always taking up navbar space.

Animation:

   - When rearranging tabs in the tabstrip, a snappier animation rate
    is now used.
   - Work continues on animations for downloads toolbar button, stop/reload
   button, and page loading indicator – but these haven’t landed yet.

Preferences:

   - The “Updates” section of preferences now shows
    the current
   Firefox version.
   - Good progress at the workweek on fixing the first set of bugs
    needed to enable
   searching within preferences.
   - UX is working on some further changes to the reorganization that we
   believe will improve it.

Visual redesign:

   - The new styling for the location and search bars
    landed.
   - The stop/reload button
    has been rem

Re: Status of support for Android on ARMv7 without NEON

[Ralph Giles]

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 -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 list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status of support for Android on ARMv7 without NEON

[haxelaar]

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 list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[Eric Rahm]

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
streaming interface, and support XML 1 v4. That's it, no new features, no
rewrite of our entire XML stack.

-e

[1] https://gist.github.com/EricRahm/f718c4d8a862cc08b69d7d4290c02927

On Mon, May 22, 2017 at 11:43 PM, 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 on both above and below expat?
>

Just expat.


> Back in 2011, I wrote a plan for rewriting the code around expat
> without rewriting expat itself:
> https://wiki.mozilla.org/Platform/XML_Rewrite
> I've had higher-priority stuff to do ever since...
>
>
Yes, I've seen this. It explicitly calls out not replacing expat, so the
plans are mostly orthogonal.


> (The above plan talks about pushing UTF-16 to the XML parser and
> having deep C++ namespaces. Any project starting this year should make
> the new parser use UTF-8 internally for cache-friendliness and use
> less deep C++ namespaces.)
>

Our current interface is UTF-16, so that's my target for now. I think
whatever cache-friendliness would be lost converting from UTF-16 -> UTF-8
-> UTF-16.


> Also, I think the decision of which XML version to support should be a
> deliberate decision and not an accident. I think the reasonable
> choices are XML 1.0 4th edition (not rocking the boat) and reviving
> XML5 (original discussion: https://annevankesteren.nl/2007/10/xml5 ,
> latest draft: https://ygg01.github.io/xml5_draft/). XML 1.1 is dead.
> XML 1.0 5th edition tried to have the XML 1.0 cake and eat the XML 1.1
> cake too and expanded the set of documents that parser doesn't reject.
> Any of the newly well-forming documents would be incompatible with 4th
> ed. and earlier parsers, which would be a break from universal XML
> interop. I think it doesn't make sense to relax XML only a bit. If XML
> is to be relaxed (breaking interop in the sense of starting to accept
> docs that old browsers would show the Yellow Screen of Death on), we
> should go all the way (i.e. XML5).
>
>
My current goal is a drop-in replacement for expat with just the features
gecko cares about, so just 1.0 version 4 I guess. It's possible whatever we
end up with could be merged with another library when XML5 is settled, but
I don't want to wait for that.


> Notably, it looks like Servo already has an XML5 parser written in Rust:
> https://github.com/servo/html5ever/tree/master/xml5ever
>
>
Yes, this lacks DTD support (and 1.0 support).


> The tweets weren't clear about whether xml5ever had been considered,
> but https://twitter.com/eroc/status/866808814959378434 looks like it's
> talking about writing a new one.
>
>
Correct, I looked at xml5ever and spoke with some folks on #servo about it.
It doesn't meet Firefox's requirements.


> It seems like integrating xml5ever (as opposed to another XML parser
> written in Rust) into Gecko would give some insight into how big a
> deal it would be to replace Gecko's HTML parser with html5ever
> (although due to document.write(), HTML is always a bigger deal
> integration-wise than XML).
>
>
That's a non-goal for me, but I can see how it would be useful.


> (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.)
>
>
That is not my current goal, but that seems reasonable regardless of this
project.


> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla Charset Detectors

[Joshua Cranmer 🐧]

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 recommendations, i see that they are C/C++ libraries but in
theory they can be wrapped into a managed C++.NET assembly and consumed by
a C# project. I haven't seen yet any existing C# ports that also handle
charset detection.


You only need charset detection if you can't get reliable charsets 
passed around. Most word processing formats embed the charset they use 
in the document (or just use UTF-8 unconditionally), so you only need 
charset detection if you're getting lots of multilingual plain text (or 
plain text-ish formats like markdown or HTML), and even then, only if 
you expect the charset information to be unreliable. It's also worth 
pointing out that letting users override the charset information on a 
per-file basis goes a very long way to avoiding the need for charset 
detection.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Michael Layzell]

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, Michael Layzell 
wrote:

> 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://github.com/mystor/nowarn
>
> Very hacky, but it helps clean up the spam of compiler warnings to let me
> actually find my build errors.
>
> On Mon, May 22, 2017 at 7:16 PM, Karl Tomlinson  wrote:
>
>> On Sat, 20 May 2017 14:59:11 -0400, Eric Rescorla wrote:
>>
>> > On Sat, May 20, 2017 at 1:16 PM, Kris Maglione 
>> > wrote:
>> >
>> >> On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote:
>> >>
>> >>> Hmm, these are all -Wsign-compare issues bar one, which is fixed
>> >>> upstream.  We have an open bug tracking the warnings
>> >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1307958 and
>> specifically
>> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1212199 for NSS).
>> >>>
>> >>> NSS is built with -Werror separately, but disables errors on
>> >>> -Wsign-compare.  Disabling those warnings for a Firefox build of NSS
>> >>> wouldn't be so bad now that we share gyp config.  Based on a recent
>> >>> build, that's 139 messages (add 36 if you want to add nspr).
>> >>>
>> >>
>> >> Is there a particularly good reason that NSS needs to disable
>> >> -Wsign-compare? That seems like a footgun waiting to happen,
>> especially in
>> >> crypto code.
>> >
>> >
>> > Like many other pieces of old code, there are a lot of things that
>> trigger
>> > compiler warnings which we have been progressively removing, but we
>> > haven't removed these yet. Ideally we would have some tooling that
>> > would distinguish new warnings from old warnings, but absent that,
>> > until we fix all the existing warnings it's either disable -Werror or
>> > disable this particular warning. It's not something we're particularly
>> > happy about.
>>
>> -Wno-error=sign-compare is also an option,
>> but a wall of sign-compare warnings may not be helpful in general.
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Michael Layzell]

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://github.com/mystor/nowarn

Very hacky, but it helps clean up the spam of compiler warnings to let me
actually find my build errors.

On Mon, May 22, 2017 at 7:16 PM, Karl Tomlinson  wrote:

> On Sat, 20 May 2017 14:59:11 -0400, Eric Rescorla wrote:
>
> > On Sat, May 20, 2017 at 1:16 PM, Kris Maglione 
> > wrote:
> >
> >> On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote:
> >>
> >>> Hmm, these are all -Wsign-compare issues bar one, which is fixed
> >>> upstream.  We have an open bug tracking the warnings
> >>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1307958 and specifically
> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1212199 for NSS).
> >>>
> >>> NSS is built with -Werror separately, but disables errors on
> >>> -Wsign-compare.  Disabling those warnings for a Firefox build of NSS
> >>> wouldn't be so bad now that we share gyp config.  Based on a recent
> >>> build, that's 139 messages (add 36 if you want to add nspr).
> >>>
> >>
> >> Is there a particularly good reason that NSS needs to disable
> >> -Wsign-compare? That seems like a footgun waiting to happen, especially
> in
> >> crypto code.
> >
> >
> > Like many other pieces of old code, there are a lot of things that
> trigger
> > compiler warnings which we have been progressively removing, but we
> > haven't removed these yet. Ideally we would have some tooling that
> > would distinguish new warnings from old warnings, but absent that,
> > until we fix all the existing warnings it's either disable -Werror or
> > disable this particular warning. It's not something we're particularly
> > happy about.
>
> -Wno-error=sign-compare is also an option,
> but a wall of sign-compare warnings may not be helpful in general.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[Axel Hecht]

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-in. (Previously, Tab from Google
was interested in making SVG parsing non-Draconian, but I have no idea
how reflective of wider buy-in that remark was.)


You also mentioned warnings in red and multi-vendor buy-in. What does that
entail?

Will lack of support for DTD be a problem? In XML5 it was decided, that
instead of parsing DTD we just store list of named character references
from
https://html.spec.whatwg.org/multipage/syntax.html#named-character-references.
While we could add another list and expand entities.json. It's possible I
need to update spec to reflect that.


Yes, not parsing DTDs would be a deal-breaker for the foreseeable 
future, as we're abusing DTDs to localize X(H)TML documents.


Axel



PS. I hope I'm not spamming you guys too hard, I'm kind of new to the
mailing list thing.

Daniel Fath,
daniel.fa...@gmail.com



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Start logging at runtime (Firefox 52)

[Valentin Gosu]

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, 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 Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> > > Hi everyone,
> > >
> > > (I meant to send this mail a few weeks ago but forgot it in my Drafts
> > > folder.)
> > >
> > > With the landing of Bug 1303762 (Firefox 52), we now have a way for
> users
> > > to enable logging without restarting the browser, and without having to
> > > know what an environment variable is.
> > >
> > > We've added a new Logging section to about:networking. When a user
> > > encounters a bug, all they have to do is open that page, click on
> "Start
> > > Logging", reproduce the bug, then click on "Stop Logging" and upload
> the
> > > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > > variables have been defined.
> > > The log modules are automatically set to the most common networking
> > > modules, but you may instruct the bug reporters to change them - just
> > tell
> > > them the string.
> > >
> > > This is very useful for bugs that are harder to reproduce once you
> > restart
> > > the browser.
> > >
> > > There are a bunch of improvements that we could make to the UI, so
> please
> > > feel free to send me your feedback and patches. Many thanks to Honza
> > > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that
> helped
> > > with the implementation and review of this bug and its dependencies.
> > >
> > > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> > HTTP_logging?document_saved=true#Using_aboutnetworking
> >
> > This seems super handy, but I tried it out and it seems to only affect
> the
> > parent process, and not the sub-processes of Firefox?
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[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-in. (Previously, Tab from Google
> was interested in making SVG parsing non-Draconian, but I have no idea
> how reflective of wider buy-in that remark was.)

You also mentioned warnings in red and multi-vendor buy-in. What does that
entail?

Will lack of support for DTD be a problem? In XML5 it was decided, that
instead of parsing DTD we just store list of named character references
from
https://html.spec.whatwg.org/multipage/syntax.html#named-character-references.
While we could add another list and expand entities.json. It's possible I
need to update spec to reflect that.

PS. I hope I'm not spamming you guys too hard, I'm kind of new to the
mailing list thing.

Daniel Fath,
daniel.fa...@gmail.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Mozilla Charset Detectors

[Gabriel Sandor]

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++ libraries but in
theory they can be wrapped into a managed C++.NET assembly and consumed by
a C# project. I haven't seen yet any existing C# ports that also handle
charset detection.

On Mon, May 22, 2017 at 5:49 PM, Henri Sivonen  wrote:

> On Mon, May 22, 2017 at 12:13 PM, Gabriel Sandor
>  wrote:
> > I recently came across the Mozilla Charset Detectors tool, at
> > https://www-archive.mozilla.org/projects/intl/chardet.html. I'm working
> on
> > a C# project where I could use a port of this library (e.g.
> > https://github.com/errepi/ude) for advanced charset detection.
>
> It's somewhat unfortunate that chardet got ported over to languages
> like Python and C# with its shortcomings. The main shortcoming is that
> despite the name saying "universal", the detector was rather arbitrary
> in what it detected and what it didn't. Why Hebrew and Thai but not
> Arabic or Vietnamese? Why have a Hungarian-specific frequency model
> (that didn't actually work) but no models for e.g. Polish and Czech
> from the same legacy encoding family?
>
> The remaining detector bits in Firefox are for Japanese, Russian and
> Ukrainian only, and I strongly suspect that the Russian and Ukrainian
> detectors are doing more harm than good.
>
> > I'm not sure however if this tool is deprecated or not, and still
> > recommended by Mozilla for use in modern applications. The tool page is
> > archived and most of the links are dead, while the code seems to be at
> > least 7-8 years old. Could you please tell me what's the status of this
> > tool and whether I should use it in my project or look for something
> else?
>
> I recommend not using it. (I removed most of it from Firefox.)
>
> I recommend avoiding heuristic detection unless your project
> absolutely can't do without. If you *really* need a detector, ICU and
> https://github.com/google/compact_enc_det/ might be worth looking at,
> though this shouldn't be read as an endorsement of either.
>
> With both ICU and https://github.com/google/compact_enc_det/ , watch
> out for the detector's possible guess space containing very rarely
> used encodings that you really don't want content detected as by
> mistake.
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[Henri Sivonen]

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 having resolutions for the issues that are currently
warnings in red and multi-vendor buy-in. (Previously, Tab from Google
was interested in making SVG parsing non-Draconian, but I have no idea
how reflective of wider buy-in that remark was.)

> Also how far reaching should spec be? Include Namespaces?

I would expect the spec to take a byte stream as input, specify how
the encoding is determined, delegate the decoding from bytes to
Unicode code points to the Encoding Standard and then define how the
code point stream is processed into a DOM tree. (Bonus points for
defining a coercion to an XML 1.0 4th ed. Infoset, too, for
non-browser use cases.) That would include the processing of
Namespaces.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[Daniel Fath]

> (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 9:01 AM, Henri Sivonen  wrote:

> 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 on both above and below expat?
> >
> > Back in 2011, I wrote a plan for rewriting the code around expat
> > without rewriting expat itself:
> > https://wiki.mozilla.org/Platform/XML_Rewrite
> > I've had higher-priority stuff to do ever since...
> >
> > (The above plan talks about pushing UTF-16 to the XML parser and
> > having deep C++ namespaces. Any project starting this year should make
> > the new parser use UTF-8 internally for cache-friendliness and use
> > less deep C++ namespaces.)
> >
> > Also, I think the decision of which XML version to support should be a
> > deliberate decision and not an accident. I think the reasonable
> > choices are XML 1.0 4th edition (not rocking the boat) and reviving
> > XML5 (original discussion: https://annevankesteren.nl/2007/10/xml5 ,
> > latest draft: https://ygg01.github.io/xml5_draft/). XML 1.1 is dead.
> > XML 1.0 5th edition tried to have the XML 1.0 cake and eat the XML 1.1
> > cake too and expanded the set of documents that parser doesn't reject.
> > Any of the newly well-forming documents would be incompatible with 4th
> > ed. and earlier parsers, which would be a break from universal XML
> > interop. I think it doesn't make sense to relax XML only a bit. If XML
> > is to be relaxed (breaking interop in the sense of starting to accept
> > docs that old browsers would show the Yellow Screen of Death on), we
> > should go all the way (i.e. XML5).
> >
> > Notably, it looks like Servo already has an XML5 parser written in Rust:
> > https://github.com/servo/html5ever/tree/master/xml5ever
> >
> > The tweets weren't clear about whether xml5ever had been considered,
> > but https://twitter.com/eroc/status/866808814959378434 looks like it's
> > talking about writing a new one.
> >
> > It seems like integrating xml5ever (as opposed to another XML parser
> > written in Rust) into Gecko would give some insight into how big a
> > deal it would be to replace Gecko's HTML parser with html5ever
> > (although due to document.write(), HTML is always a bigger deal
> > integration-wise than XML).
> >
> > (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.)
> >
> > --
> > Henri Sivonen
> > hsivo...@hsivonen.fi
> > https://hsivonen.fi/
>
>
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Scope of XML parser rewrite?

[Henri Sivonen]

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 on both above and below expat?
>
> Back in 2011, I wrote a plan for rewriting the code around expat
> without rewriting expat itself:
> https://wiki.mozilla.org/Platform/XML_Rewrite
> I've had higher-priority stuff to do ever since...
>
> (The above plan talks about pushing UTF-16 to the XML parser and
> having deep C++ namespaces. Any project starting this year should make
> the new parser use UTF-8 internally for cache-friendliness and use
> less deep C++ namespaces.)
>
> Also, I think the decision of which XML version to support should be a
> deliberate decision and not an accident. I think the reasonable
> choices are XML 1.0 4th edition (not rocking the boat) and reviving
> XML5 (original discussion: https://annevankesteren.nl/2007/10/xml5 ,
> latest draft: https://ygg01.github.io/xml5_draft/). XML 1.1 is dead.
> XML 1.0 5th edition tried to have the XML 1.0 cake and eat the XML 1.1
> cake too and expanded the set of documents that parser doesn't reject.
> Any of the newly well-forming documents would be incompatible with 4th
> ed. and earlier parsers, which would be a break from universal XML
> interop. I think it doesn't make sense to relax XML only a bit. If XML
> is to be relaxed (breaking interop in the sense of starting to accept
> docs that old browsers would show the Yellow Screen of Death on), we
> should go all the way (i.e. XML5).
>
> Notably, it looks like Servo already has an XML5 parser written in Rust:
> https://github.com/servo/html5ever/tree/master/xml5ever
>
> The tweets weren't clear about whether xml5ever had been considered,
> but https://twitter.com/eroc/status/866808814959378434 looks like it's
> talking about writing a new one.
>
> It seems like integrating xml5ever (as opposed to another XML parser
> written in Rust) into Gecko would give some insight into how big a
> deal it would be to replace Gecko's HTML parser with html5ever
> (although due to document.write(), HTML is always a bigger deal
> integration-wise than XML).
>
> (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.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/



-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform