Stop using PL_strchr/strstr et al for parsing - use mozilla::Tokenizer

[Honza Bambas]

I've recently introduced a class making parsing string inputs much safer 
and simpler.  Please see xpcom/ds/Tokenizer.h.  It's simplification of a 
lexical analyzer and it successfully hides boundary checks on the input 
buffer from consumers.  From now on this simple parser class should be 
used instead of any complicated strstr/strchr/Find/Substring unreadable 
and dangerous constructions.


Tokenizer is simply constructed with a string.  It then automatically 
cuts and converts the input for you to words, numbers, white spaces and 
special characters as you read it, be it a simple while loop or a 
complex recursive descent.


For details and examples see my post at 
http://www.janbambas.cz/string-parsing-made-simple-with-mozillatokenizer/


It's brand new, any suggestions on its API greatly welcomed :)

Cheers
-hb-

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

Intent to implement: directory picking and directory drag and drop

[Jonathan Watt]

MS has a proposal for a minimal set of functionality to support directory 
picking via  and to support directory drag and drop.


  https://microsoftedge.github.io/directory-upload/proposal.html

This spec is a work in progress but we now have an implementation for platforms 
that have a native directory picker (desktop) landed and turned on in Nightly 
only (the boolean pref is dom.input.dirpicker). The bug for keeping pace with 
spec changes and eventually shipping is:


  https://bugzilla.mozilla.org/show_bug.cgi?id=110

Currently we're waiting for MS to officially take their proposal to one of the 
W3C groups, probably either one of:


  https://lists.w3.org/Archives/Public/public-webapps/
  https://lists.w3.org/Archives/Public/public-wicg/

Once that happens my expectation is that the proposal will change as feedback 
comes in. Once things look stable enough to ship I'll send out an intent to ship.


For those who are interested I have a test page that demonstrates the API at:

  https://jwatt.org/tmp/directory.html

If you file any bugs please CC me and mark them as blocking bug 110.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stop using PL_strchr/strstr et al for parsing - use mozilla::Tokenizer

[Kyle Huey]

On Wed, Jul 29, 2015 at 7:15 AM, Honza Bambas  wrote:
> I've recently introduced a class making parsing string inputs much safer and
> simpler.  Please see xpcom/ds/Tokenizer.h.  It's simplification of a lexical
> analyzer and it successfully hides boundary checks on the input buffer from
> consumers.  From now on this simple parser class should be used instead of
> any complicated strstr/strchr/Find/Substring unreadable and dangerous
> constructions.
>
> Tokenizer is simply constructed with a string.  It then automatically cuts
> and converts the input for you to words, numbers, white spaces and special
> characters as you read it, be it a simple while loop or a complex recursive
> descent.
>
> For details and examples see my post at
> http://www.janbambas.cz/string-parsing-made-simple-with-mozillatokenizer/
>
> It's brand new, any suggestions on its API greatly welcomed :)
>
> Cheers
> -hb-
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Can we rewrite nsCharSeparatedTokenizer on top of this?

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

Re: Intent to implement: directory picking and directory drag and drop

[Anne van Kesteren]

On Wed, Jul 29, 2015 at 5:37 PM, Jonathan Watt  wrote:
> MS has a proposal for a minimal set of functionality to support directory
> picking via  and to support directory drag and drop.
>
>   https://microsoftedge.github.io/directory-upload/proposal.html

It doesn't seem to define how it affects the FormData API.

Also, it would be clearer if the language was written in the same
style as every other HTML form feature is defined in... I guess that's
for later.


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

XULRunner future and ownership

[Benjamin Smedberg]

The Mozilla project no longer sees XULRunner as a priority project. It's 
not core to advancing the open web or any of our current or planned 
products.


As Ben Hearsum noted a couple weeks ago, we are turning off automated 
XULRunner builds and so XULRunner will probably quickly cease to work. 
In order to keep XULRunner in the tree, we need an owner who wants to 
keep it building and running properly. Currently, I am the nominal owner 
of the XULRunner code, but I have no desire to do this work or even 
really to review the necessary patches. I am looking to see whether 
there is an alternate owner who is interested in the task of keeping 
XULRunner building and running properly and reviewing patches to 
XULRuner-specific code. Please contact me if you want to nominate 
yourself or somebody else for this role.


If I do not find a suitable owner in the next two weeks, I intend to 
remove the XULRunner code from the mozilla-central repository on 14-August.


--BDS

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

Re: Stop using PL_strchr/strstr et al for parsing - use mozilla::Tokenizer

[Honza Bambas]

On 7/29/2015 19:40, Kyle Huey wrote:

On Wed, Jul 29, 2015 at 7:15 AM, Honza Bambas  wrote:

I've recently introduced a class making parsing string inputs much safer and
simpler.  Please see xpcom/ds/Tokenizer.h.  It's simplification of a lexical
analyzer and it successfully hides boundary checks on the input buffer from
consumers.  From now on this simple parser class should be used instead of
any complicated strstr/strchr/Find/Substring unreadable and dangerous
constructions.

Tokenizer is simply constructed with a string.  It then automatically cuts
and converts the input for you to words, numbers, white spaces and special
characters as you read it, be it a simple while loop or a complex recursive
descent.

For details and examples see my post at
http://www.janbambas.cz/string-parsing-made-simple-with-mozillatokenizer/

It's brand new, any suggestions on its API greatly welcomed :)

Cheers
-hb-

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

Can we rewrite nsCharSeparatedTokenizer on top of this?


Hmm.. we definitely could, nsCharSeparatedTokenizer would then become 
just an adapter over Tokenizer.  nsCharSeparatedTokenizer seems to be 
widely used, that prevents me from saying "let's convert all places to 
use Tokenizer".  That seems like a bigger task. nsCharSeparatedTokenizer 
is simpler with simpler (but IMO not perfect) API.  Hence the migration 
might end up with a more complicated code.  I'll go through it case by 
case quickly and see. Filed 
https://bugzilla.mozilla.org/show_bug.cgi?id=1188991 on it.


-hb-





- Kyle



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

Re: XULRunner future and ownership

[Fabrice Desré]

On Wed, 29 Jul 2015 14:30:00 -0400, Benjamin Smedberg wrote:

> If I do not find a suitable owner in the next two weeks, I intend to
> remove the XULRunner code from the mozilla-central repository on
> 14-August.

Two weeks during summer time seems a bit short. You may not get 
interested people that are vacationing.

 Fabrice

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

Re: Stop using PL_strchr/strstr et al for parsing - use mozilla::Tokenizer

[Daniel Stenberg]

On Wed, 29 Jul 2015, Honza Bambas wrote:

I've recently introduced a class making parsing string inputs much safer and 
simpler.



http://www.janbambas.cz/string-parsing-made-simple-with-mozillatokenizer/


Nice! How does it act when hitting 64bit integer overflows?

--

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

Re: XULRunner future and ownership

[Gregory Szorc]

On Wed, Jul 29, 2015 at 1:07 PM, Fabrice Desré  wrote:

> On Wed, 29 Jul 2015 14:30:00 -0400, Benjamin Smedberg wrote:
>
> > If I do not find a suitable owner in the next two weeks, I intend to
> > remove the XULRunner code from the mozilla-central repository on
> > 14-August.
>
> Two weeks during summer time seems a bit short. You may not get
> interested people that are vacationing.
>

The old code will still be there in version control. If an owner emerges
after 2 weeks, we can always revert the delete.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[Mike de Boer]

I’d like to volunteer.

Not much more to say, really :-)

Cheers,

Mike.

> On 29 Jul 2015, at 20:30, Benjamin Smedberg  wrote:
> 
> The Mozilla project no longer sees XULRunner as a priority project. It's not 
> core to advancing the open web or any of our current or planned products.
> 
> As Ben Hearsum noted a couple weeks ago, we are turning off automated 
> XULRunner builds and so XULRunner will probably quickly cease to work. In 
> order to keep XULRunner in the tree, we need an owner who wants to keep it 
> building and running properly. Currently, I am the nominal owner of the 
> XULRunner code, but I have no desire to do this work or even really to review 
> the necessary patches. I am looking to see whether there is an alternate 
> owner who is interested in the task of keeping XULRunner building and running 
> properly and reviewing patches to XULRuner-specific code. Please contact me 
> if you want to nominate yourself or somebody else for this role.
> 
> If I do not find a suitable owner in the next two weeks, I intend to remove 
> the XULRunner code from the mozilla-central repository on 14-August.
> 
> --BDS
> 
> ___
> 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: XULRunner future and ownership

[Benjamin Kerensa]

XULRunner is dead, Long live XULRunner!

On Wed, Jul 29, 2015 at 11:30 AM, Benjamin Smedberg 
wrote:

> The Mozilla project no longer sees XULRunner as a priority project. It's
> not core to advancing the open web or any of our current or planned
> products.
>
> As Ben Hearsum noted a couple weeks ago, we are turning off automated
> XULRunner builds and so XULRunner will probably quickly cease to work. In
> order to keep XULRunner in the tree, we need an owner who wants to keep it
> building and running properly. Currently, I am the nominal owner of the
> XULRunner code, but I have no desire to do this work or even really to
> review the necessary patches. I am looking to see whether there is an
> alternate owner who is interested in the task of keeping XULRunner building
> and running properly and reviewing patches to XULRuner-specific code.
> Please contact me if you want to nominate yourself or somebody else for
> this role.
>
> If I do not find a suitable owner in the next two weeks, I intend to
> remove the XULRunner code from the mozilla-central repository on 14-August.
>
> --BDS
>
> ___
> dev-planning mailing list
> dev-plann...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
>



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

On the future of and application/x-x509-*-cert MIME handling

[David Keeler]

[cc'd to dev-security for visibility. This discussion is intended to
happen on dev-platform; please reply to that list.]

Ryan Sleevi recently announced the pre-intention to deprecate and
eventually remove support for the  element and special-case
handling of the application/x-x509-*-cert MIME types from the blink
platform (i.e. Chrome).

Rather than reiterate his detailed analysis, I'll refer to the post here:

https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

Much, if not all, of that reasoning applies to gecko as well.
Furthermore, it would be a considerable architectural improvement if
gecko were to remove these features (particularly with respect to e10s).
Additionally, if they were removed from blink, the compatibility impact
of removing them from gecko would be lessened.

I therefore propose we follow suit and begin the process of deprecating
and removing these features. The intention of this post is to begin a
discussion to determine the feasibility of doing so.

Cheers,
David



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: XULRunner future and ownership

[Eric Shepherd]

Benjamin Smedberg wrote:
> I am looking to see whether there is an alternate owner who is
> interested in the task of keeping XULRunner building and running
> properly and reviewing patches to XULRuner-specific code. Please
> contact me if you want to nominate yourself or somebody else for this
> role. 
I should note also that the MDN staff can't put any time into helping
with XULRunner specific documentation anymore, so any documentation work
would have to be taken up by the person or people that pick up the project.

I would, however, be quite happy to spend some time helping whoever
takes on that work -- or whoever picks up writing work for it -- on
exactly how to contribute the needed material to MDN.

-- 

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Check my Availability 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform