Re: Intent to unship: window.showModalDialog

2017-06-07 Thread jm . acuna73 
In one of my projects we have replaced this method with the  tag that 
only supports Google Chrome.
It would be interesting that when window.showModalDialog is turned off, the 
dialog element is operational.

When do you want to implement the dialog tag html5?

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

Intent to unship: window.showModalDialog

2017-06-07 Thread Blake Kaplan 
Hey all,

3 years ago (!) sicking commented in bug 981796 [1] that we were removing
window.showModalDialog. The following year, I wrote a patch to disable it via
a pref at the same time as pushing some telemetry to try to track usage. We
saw more usage than we were hoping, so we held off on turning it off then.
That being said, we didn't implement window.showModalDialog in e10s, so it's
been disabled for those users since (about) Firefox 48.

It's time to turn off window.showModalDialog for the rest of the users. For
the time being, we'll hide it behind a pref and look to remove the code in the
next couple of cycles.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=981796
-- 
Blake Kaplan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling

2017-06-07 Thread Simon Sapin 

On 07/06/17 12:45, Henri Sivonen wrote:

It seems to me that this episode has revealed that the Unicode
Consortium doesn't have an objective way to deem one way of doing
things as clearly the best one, so it seems to me that there's a
better chance of Unicode toning down the language expresses a
preference to make it a lesser preference (by calling it something
lesser than "best practice" going forward) and it seems to me that
there wouldn't be Unicode-level agreement of elevating the old or the
new preference to a requirement on the Unicode level. The WHATWG spec
would continue to make the old Unicode preference required, so I think
it's an OK outcome for the requirement to live in the WHATWG spec and
Unicode preferring the same thing (i.e. reverting the change to the
preference) in weaker terms than so far. Letting it be this way
wouldn't invite objections from non-Web-oriented implementors who
implement something else that's currently within Unicode compliance
and who don't want to change any code.


I agree with Henri on the original issue.

I also agree that it’s probably easier to not also try to make this a 
strong requirement. When you ask for two things at the same time it’s 
easy for someone to respond to / argue about one and forget the other, 
deliberately or not.


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

Re: Sheriff Survey started & Sheriff Statistics May 2017

2017-06-07 Thread Carsten Book 
since some people had problems filing out the survey - some better links :)

http://bit.ly/2s4rACF -
https://docs.google.com/a/mozilla.com/forms/d/e/1FAIpQLSfGBZ50zkG9W-Wnk1ACBfFvj1iu8e46I5gs9t-G3ZWDpcy4-A/viewform


sorry
- Tomcat



On Wed, Jun 7, 2017 at 10:58 AM, Carsten Book  wrote:

> Hi,
>
> just one second before i start into statistics
>
> One thing i love at Mozilla is that there is no general "that's the way we
> have always done it.." - we at Mozilla also try to improve things - our
> Software but also our processes and so its also with Sheriffing - We try to
> optimize our workflow/processes constantly to make your live as developer
> easier when working with us but ... we rely also on your feedback :)
>
> So we created a Survey for YOU to give us Feedback about how we do and
> also where we can improve. This input/Feedback from you is very valuable
> for us!
>
> You can find the Survey at http://bit.ly/2rzMjNi -
> https://docs.google.com/a/mozilla.com/forms/d/1a8QmBraKjW750WVU01pbsWwE-
> KU2j10dHHWJx5cGi0g
>
> Thanks for taking part in the Survey!
>
> and now the Statistics for May 2017
>
> *May 2017:*
>
> *Autoland Tree:*
>
> Total Servo Sync Pushes: 266
> Total Pushes: 1848
> Total Number of commits 3959
> Total number of commits without Servo 3664
> Total Backouts: 157
> Total of Multi-bug pushes 14
> Total number of bugs changed 1714
> Percentage of backout against bugs: 9.15985997666
> Percentage of backouts: 8.49567099567
> Percentage of backouts without Servo: 9.92414664981 (also more commits in
> May compared April and backout rate drop of  -0,6 %)
>
> *Mozilla-inbound*
>
> Total Servo Sync Pushes: 0
> Total Pushes: 1059
> Total Number of commits 3823
> Total number of commits without Servo 3823
> Total Backouts: 116
> Total of Multi-bug pushes 178
> Total number of bugs changed 1433
> Percentage of backout against bugs: 8.09490579204
> Percentage of backouts: 10.9537299339
> Percentage of backouts without Servo: 10.9537299339 (more pushes in May
> compared to April and -3 % drop of the backout rate!
>
>
> So Sheriffs managed and monitored on the Integration Trees in May 2017 ~
> 2900 pushes and 335 backouts.
>
> Let us know when you have any Question or Feedback about Sheriffing.
>
> Cheers and have a great June!,
> -Tomcat
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling

2017-06-07 Thread Henri Sivonen 
On Wed, Jun 7, 2017 at 12:16 PM, Jet Villegas  wrote:
> SGTM,

Thanks.

> Thanks for pushing on this one.
>
> One comment: although this is a proposed change to non-normative spec
> text, it appears that several implementations already implement the
> original (also non-normative) recommendation. Would it be worthwhile
> to propose the reversal and also mark the section as normative?

It seems to me that this episode has revealed that the Unicode
Consortium doesn't have an objective way to deem one way of doing
things as clearly the best one, so it seems to me that there's a
better chance of Unicode toning down the language expresses a
preference to make it a lesser preference (by calling it something
lesser than "best practice" going forward) and it seems to me that
there wouldn't be Unicode-level agreement of elevating the old or the
new preference to a requirement on the Unicode level. The WHATWG spec
would continue to make the old Unicode preference required, so I think
it's an OK outcome for the requirement to live in the WHATWG spec and
Unicode preferring the same thing (i.e. reverting the change to the
preference) in weaker terms than so far. Letting it be this way
wouldn't invite objections from non-Web-oriented implementors who
implement something else that's currently within Unicode compliance
and who don't want to change any code.

> --Jet
>
> On Wed, Jun 7, 2017 at 2:11 AM, Henri Sivonen  wrote:
>> (If you don't care about the details of UTF-8 error handling, it's
>> safe to stop reading.)
>>
>> In reference to https://hsivonen.fi/broken-utf-8/ , I think it would
>> be appropriate to submit that post to the Unicode Consortium with a
>> cover note asking the Unicode Technical Committee to revert their
>> decision to change the preferred UTF-8 error handling for Unicode 11
>> and to retract the action item to draft corresponding new text for
>> Unicode 11 for reasons given in the post.
>>
>> I think it would be preferable to do this via Mozilla's liaison
>> membership of the Unicode Consortium rather than me doing it as a
>> random member of the public, because submission via Mozilla's liaison
>> membership allows for visibility into the process and opportunity for
>> follow-up whereas if I do it on my own, it's basically a matter of
>> dropping a note into a one-way black box. (It seems that this kind of
>> thing is exactly what Mozilla's liaison membership is for.)
>>
>> However, submitting via Mozilla's liaison membership raises the
>> question of whether the submission would properly represent a Mozilla
>> consensus. I estimate this to be noncontroversial, because deliberate
>> effort has been expended to make the Mozilla-affiliated
>> implementations that I am aware of (uconv, encoding_rs and the Rust
>> standard library) behave according to the pre-Unicode 11 version of
>> the guidance either directly by looking at the Unicode Standard or by
>> the way of implementing the WHATWG Encoding Standard, which elevates
>> the pre-Unicode 11 preferred approach into a requirement.
>>
>> If I have mis-guessed that the above-contemplated submission should be
>> non-controversial from the Mozilla perspective and you believe that
>> the above-contemplated submission should not be made via Mozilla's
>> liaison membership, please let me know.
>>
>> (My understanding is that a reversal of the decision is quite
>> possible, but actually making the above-contemplated submission is a
>> process prerequisite for a reversal to take place.)
>>
>> --
>> Henri Sivonen
>> hsivo...@hsivonen.fi
>> https://hsivonen.fi/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform



-- 
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: Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling

2017-06-07 Thread Jet Villegas 
SGTM, Thanks for pushing on this one.

One comment: although this is a proposed change to non-normative spec
text, it appears that several implementations already implement the
original (also non-normative) recommendation. Would it be worthwhile
to propose the reversal and also mark the section as normative?

--Jet

On Wed, Jun 7, 2017 at 2:11 AM, Henri Sivonen  wrote:
> (If you don't care about the details of UTF-8 error handling, it's
> safe to stop reading.)
>
> In reference to https://hsivonen.fi/broken-utf-8/ , I think it would
> be appropriate to submit that post to the Unicode Consortium with a
> cover note asking the Unicode Technical Committee to revert their
> decision to change the preferred UTF-8 error handling for Unicode 11
> and to retract the action item to draft corresponding new text for
> Unicode 11 for reasons given in the post.
>
> I think it would be preferable to do this via Mozilla's liaison
> membership of the Unicode Consortium rather than me doing it as a
> random member of the public, because submission via Mozilla's liaison
> membership allows for visibility into the process and opportunity for
> follow-up whereas if I do it on my own, it's basically a matter of
> dropping a note into a one-way black box. (It seems that this kind of
> thing is exactly what Mozilla's liaison membership is for.)
>
> However, submitting via Mozilla's liaison membership raises the
> question of whether the submission would properly represent a Mozilla
> consensus. I estimate this to be noncontroversial, because deliberate
> effort has been expended to make the Mozilla-affiliated
> implementations that I am aware of (uconv, encoding_rs and the Rust
> standard library) behave according to the pre-Unicode 11 version of
> the guidance either directly by looking at the Unicode Standard or by
> the way of implementing the WHATWG Encoding Standard, which elevates
> the pre-Unicode 11 preferred approach into a requirement.
>
> If I have mis-guessed that the above-contemplated submission should be
> non-controversial from the Mozilla perspective and you believe that
> the above-contemplated submission should not be made via Mozilla's
> liaison membership, please let me know.
>
> (My understanding is that a reversal of the decision is quite
> possible, but actually making the above-contemplated submission is a
> process prerequisite for a reversal to take place.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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

Consensus check: Asking the Unicode Technical Committee to revert their decision to change the preferred UTF-8 error handling

2017-06-07 Thread Henri Sivonen 
(If you don't care about the details of UTF-8 error handling, it's
safe to stop reading.)

In reference to https://hsivonen.fi/broken-utf-8/ , I think it would
be appropriate to submit that post to the Unicode Consortium with a
cover note asking the Unicode Technical Committee to revert their
decision to change the preferred UTF-8 error handling for Unicode 11
and to retract the action item to draft corresponding new text for
Unicode 11 for reasons given in the post.

I think it would be preferable to do this via Mozilla's liaison
membership of the Unicode Consortium rather than me doing it as a
random member of the public, because submission via Mozilla's liaison
membership allows for visibility into the process and opportunity for
follow-up whereas if I do it on my own, it's basically a matter of
dropping a note into a one-way black box. (It seems that this kind of
thing is exactly what Mozilla's liaison membership is for.)

However, submitting via Mozilla's liaison membership raises the
question of whether the submission would properly represent a Mozilla
consensus. I estimate this to be noncontroversial, because deliberate
effort has been expended to make the Mozilla-affiliated
implementations that I am aware of (uconv, encoding_rs and the Rust
standard library) behave according to the pre-Unicode 11 version of
the guidance either directly by looking at the Unicode Standard or by
the way of implementing the WHATWG Encoding Standard, which elevates
the pre-Unicode 11 preferred approach into a requirement.

If I have mis-guessed that the above-contemplated submission should be
non-controversial from the Mozilla perspective and you believe that
the above-contemplated submission should not be made via Mozilla's
liaison membership, please let me know.

(My understanding is that a reversal of the decision is quite
possible, but actually making the above-contemplated submission is a
process prerequisite for a reversal to take place.)

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

Sheriff Survey started & Sheriff Statistics May 2017

2017-06-07 Thread Carsten Book 
Hi,

just one second before i start into statistics

One thing i love at Mozilla is that there is no general "that's the way we
have always done it.." - we at Mozilla also try to improve things - our
Software but also our processes and so its also with Sheriffing - We try to
optimize our workflow/processes constantly to make your live as developer
easier when working with us but ... we rely also on your feedback :)

So we created a Survey for YOU to give us Feedback about how we do and also
where we can improve. This input/Feedback from you is very valuable for us!

You can find the Survey at http://bit.ly/2rzMjNi -
https://docs.google.com/a/mozilla.com/forms/d/1a8QmBraKjW750WVU01pbsWwE-KU2j10dHHWJx5cGi0g

Thanks for taking part in the Survey!

and now the Statistics for May 2017

*May 2017:*

*Autoland Tree:*

Total Servo Sync Pushes: 266
Total Pushes: 1848
Total Number of commits 3959
Total number of commits without Servo 3664
Total Backouts: 157
Total of Multi-bug pushes 14
Total number of bugs changed 1714
Percentage of backout against bugs: 9.15985997666
Percentage of backouts: 8.49567099567
Percentage of backouts without Servo: 9.92414664981 (also more commits in
May compared April and backout rate drop of  -0,6 %)

*Mozilla-inbound*

Total Servo Sync Pushes: 0
Total Pushes: 1059
Total Number of commits 3823
Total number of commits without Servo 3823
Total Backouts: 116
Total of Multi-bug pushes 178
Total number of bugs changed 1433
Percentage of backout against bugs: 8.09490579204
Percentage of backouts: 10.9537299339
Percentage of backouts without Servo: 10.9537299339 (more pushes in May
compared to April and -3 % drop of the backout rate!


So Sheriffs managed and monitored on the Integration Trees in May 2017 ~
2900 pushes and 335 backouts.

Let us know when you have any Question or Feedback about Sheriffing.

Cheers and have a great June!,
-Tomcat
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform