Re: Rust required to build Gecko

[Mike Hommey]

On Wed, Dec 21, 2016 at 12:41:37AM -0600, J. Ryan Stinnett wrote:
> On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy 
> wrote:
> > I had a .mozconfig file that included the line:
> >
> > . "$topsrcdir/build/mozconfig.common"
> 
> My understanding is that we're generally not supposed to include the
> in-tree mozconfigs in our local builds, since they are free to make
> various automation-only assumptions, which seems to be what happened
> here. It's tempting to do it anyway though, for some abstract feeling
> that the build will more closely resemble an official one. (I used to
> do something like this as well!)

Note that a lot of the flags set by in-tree mozconfigs are now redundant
with defaults you get without a mozconfig. While that's not entirely
true, it's a goal to have the in-tree mozconfigs to eventually *only*
contain automation-specific things (or very specific things like API
keys, update channel, etc.)

> I believe many people have fallen into this trap over the years, most
> likely because of MDN pages[1] that appeared to suggest using
> automation mozconfigs directly (there's at least a warning on the page
> now).

I filed bug 1324998 to put an end to this bad habit once and for all.

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

Re: Rust required to build Gecko

[Jim Blandy]

All the more reason for "mach" to be the exclusive place to put all these
smarts.

The only things I really want anyway are:

mk_add_options MOZ_OBJDIR=obj-bug
ac_add_options --enable-debug='-g3 -O0 -fno-inline'
ac_add_options --disable-optimize


On Tue, Dec 20, 2016 at 10:41 PM, J. Ryan Stinnett  wrote:

> On Wed, Dec 21, 2016 at 12:23 AM, Jim Blandy  wrote:
> > I had a .mozconfig file that included the line:
> >
> > . "$topsrcdir/build/mozconfig.common"
>
> My understanding is that we're generally not supposed to include the
> in-tree mozconfigs in our local builds, since they are free to make
> various automation-only assumptions, which seems to be what happened
> here. It's tempting to do it anyway though, for some abstract feeling
> that the build will more closely resemble an official one. (I used to
> do something like this as well!)
>
> I believe many people have fallen into this trap over the years, most
> likely because of MDN pages[1] that appeared to suggest using
> automation mozconfigs directly (there's at least a warning on the page
> now).
>
> [1]: https://developer.mozilla.org/en-US/docs/Mozilla/Developer_
> guide/Build_Instructions/Configuring_Build_Options#
> Example_.mozconfig_Files
>
> - Ryan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust required to build Gecko

[Jim Blandy]

I had a .mozconfig file that included the line:

. "$topsrcdir/build/mozconfig.common"

This turns out to cause problems: it loads build/mozconfig.rust, which says
to look for rustc in $topsrcdir/rustc/bin, leading to errors like this:

 0:05.53 checking for rustc... not found
 0:05.53 DEBUG: rustc: Trying /home/jimb/moz/dbg/rustc/bin/rustc
 0:05.53 ERROR: Cannot find rustc
 0:05.54 *** Fix above errors and then restart with\
 0:05.54"/usr/bin/gmake -f client.mk build"
 0:05.54 client.mk:375: recipe for target 'configure' failed
 0:05.54 gmake: *** [configure] Error 1

I remove the line loading mozconfig.common and things seem to be going well.




On Fri, Dec 16, 2016 at 3:06 PM, Simon Sapin  wrote:

> On 16/12/16 19:26, Ralph Giles wrote:
>
>> Anyway, thanks for the suggestion, Simon. I filed
>> https://bugzil.la/1324040 with this fix.
>>
>> In the meantime, the curl command line from https://rustup.rs/ should
>> work equivalently.
>>
>
> Oops, I wrote this earlier and forgot to click Send.
>
> --
>
> http://docs.python-requests.org/en/master/community/faq/#wha
> t-are-hostname-doesn-t-match-errors says that Python 2.7.9+ supports SNI
> natively.
>
> It looks like Requests can make it work on older Python if some other
> libraries (including PyOpenSSL) are available:
>
> https://stackoverflow.com/questions/18578439/using-requests-
> with-tls-doesnt-give-sni-support/18579484#18579484
>
> --
> Simon Sapin
>
> ___
> 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: Intent to ship: NetworkInformation

[Steve Fink]

On 12/19/2016 06:21 PM, Edmund Wong wrote:

Eric Rescorla wrote:

I'm also concerned that this spec does not seem to take into account
multipath or multihoming, both of which seem relevant here. Say that I have
a device with both a cellular and WiFi link and I attempt to use both of
them in some fashion (depending on the remote IP address), what should I be
reporting for Network Connection?

Why does it matter to Firefox what network connection I use?  I would
understand Firefox needing telemetry on system specs and how it runs
against this spec, but network information?  Really?

I mean... what's wrong with:

Firefox: Can I connect to the Internet?

Yes: Great. Proceed to connect.
No:  Cannot connect.  Display message. Wait for user to fix issue.

Why does Firefox (or anyone other than me) CARE I have 1, 2, or a
billion network interfaces or what type they are?  Its job is to browse
the Internet.  THAT'S IT.  If Chrome wants to add it, that's their
business.



Because if extra bandwidth is going to cost me a week's wages, I would 
rather Firefox not prefetch all the links it sees on a page and look up 
DNS info for all of them plus anything found in them. And unfortunately, 
there's no simple way to guess whether the marginal bandwidth cost is 
zero or my meal budget for the next month. Simply looking at the type of 
one network interface isn't really enough.


That's not really a fair example, btw, since we're talking about a 
content-exposed API here. But the same idea holds -- the web site I'm 
visiting might not want to annoy me with 200 full motion thumbnail gifs 
if it knows I'm on a metered connection.


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

Re: Intent to deprecate: Insecure HTTP

[Steve Fink]

On 12/20/2016 06:20 PM, Edmund Wong wrote:

Richard Barnes wrote:


Broadly speaking, this plan would entail  limiting new features to secure
contexts, followed by gradually removing legacy features from insecure
contexts.  Having an overall program for HTTP deprecation makes a clear
statement to the web community that the time for plaintext is over -- it

There is nothing wrong with plaintext just as long as it isn't something
credential-like.  Also, what you're doing will only make a clear
statement to the web community that you are forcing something on them
and limiting THEIR choices of broadcasting their information as they
see fit.

IOW, "deprecating HTTP" is not a good idea.


If I have a browser exploit that I can embed in a 

Re: Intent to deprecate: Insecure HTTP

[Edmund Wong]

Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.

With all due respects, the HTTP->HTTPS *isn't* entirely a web
developer's choice; but the web server administration choice (unless
the person is wearing both hats).

Just because the US Government is calling for encryption (i.e. HTTPS
over HTTP), it doesn't mean people can and/or will do it.  Why?
Why do people need to be forced to use HTTPS when it's overkill for
their website?  I mean.. would a run-of-the-mill-with-no-shopping
require HTTPS?

Like, i.e http://www.ambrosia-oysterbar.com/catalog/index.php

HTTPS is a secured method of transporting information.  For the
above website,  https would mean absolutely no sense and would
be akin to getting BRINKS to transporting a T-bone steak dinner
to you.  Can you do that?  Sure possibly if BRINKS doesn't ignore
you right out.  Why would you do that?

Like everything, HTTPS is a tool and it's a bad idea
to force people to use HTTPS when they don't need it.  When
do they need it?  Who decides when they need it?  Certainly not
you, or anyone else other than themselves.

So like the NetworkInterface issue...  please stop wasting
resources doing these 'busy' things when you can be doing something
else that gives more choice to the user.  I mean.. doing the things
right vs. doing the right things and I believe it was the late Peter
Drucker that wrote that.

> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it

There is nothing wrong with plaintext just as long as it isn't something
credential-like.  Also, what you're doing will only make a clear
statement to the web community that you are forcing something on them
and limiting THEIR choices of broadcasting their information as they
see fit.

IOW, "deprecating HTTP" is not a good idea.

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

Re: Intent to implement: HTML5 element

[Xidorn Quan]

On Wed, Dec 21, 2016, at 12:23 PM, Ben Kelly wrote:

> On Tuesday, December 20, 2016, Xidorn Quan  wrote:

> > On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:

> >> Hi Tim, can you describe how the modality of dialog.showModal()
> >> works?
> >> Does a web page have the power to block the user from interacting

> >> with the entire browser (all windows)? Or is it just one window?

> >> or just one tab? or something else?

> >

> > It just blocks the same document it is in (not even the tab if the

> > document is in iframe). A modal  is just another normal HTML
> > element with some special rendering (and focusing) rules.

> 

> So dialog.showModal() does not need to block script like other
> modal APIs?


Definitely not. I think this is designed to replace those blocking API.


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

Re: Intent to implement: HTML5 element

[Xidorn Quan]

On Wed, Dec 21, 2016, at 11:21 AM, Tantek Çelik wrote:
> I'm also curious how interactions between dialog.showModal() and then
> controls inside of that going Fullscreen work (and then perhaps a
> dialog inside that fullscreen view, etc.) 

That's a... good question.

Per spec, it should just work. I mean, the document would enter
fullscreen, and dialog inside fullscreen view can be open as normal.

> Does "escape" key escape out of one layer of dialog/fullscreen? multiple? all?

I think, ideally "escape" key would exit fullscreen without touching any
modal dialog, whatever the opening order is. It is important for
security consideration, since otherwise the content may block user from
exiting fullscreen. I think implementor needs to take care of that (and
test should be added to verify this is guaranteed).

Another security concern is that this may allow websites to fool users
about what content is actually showing fullscreen. e.g. if I have
https://www.youtube.com/something; allowfullscreen>, when
Youtube enters fullscreen, Firefox shows a message stating that
youtube.com is in full screen, but with modal dialog, the parent
document can actually show something different on top of the iframe.

Probably this is already doable via making the iframe and its backdrop
pseudo transparent, so it may not be a new concern. Not sure how
important this issue is. I guess we should change the fullscreen warning
to always show the origin of the top browsing context rather than the
current fullscreen document.

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

Re: Intent to implement: HTML5 element

[Astley Chen]

A simple example if you are interested in how it works on Chrome.

http://codepen.io/astleychen/pen/Obqzrr 



—--
Best Regards,
Astley Chen | Mozilla Taiwan


On 21 Dec 2016, at 8:21 AM, Xidorn Quan  wrote:

On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal  is just another normal HTML
element with some special rendering (and focusing) rules.

- 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: Intent to implement: HTML5 element

[Tantek Çelik]

I'm also curious how interactions between dialog.showModal() and then
controls inside of that going Fullscreen work (and then perhaps a
dialog inside that fullscreen view, etc.) Does "escape" key escape out
of one layer of dialog/fullscreen? multiple? all?

Tantek

On Tue, Dec 20, 2016 at 4:12 PM, Mats Palmgren  wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?
>
> Thanks,
> Mats
>
>
> ___
> 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: Intent to implement: HTML5 element

[Xidorn Quan]

On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal  is just another normal HTML
element with some special rendering (and focusing) rules.

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

Intent to implement and ship: CSS caret-color property

[Xidorn Quan]

Summary: As the name indicates, it allows developers to change the color
or caret.

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

Link to standard: https://drafts.csswg.org/css-ui-3/#insertion-caret

Platform coverage: All platforms

Estimated or target release: Firefox 53

Preference behind which this will be implemented: No pref. Intent to
ship by default since it's a small feature which is simple and
considered stable enough.

DevTools bug: None. I don't think there is anything specific to this
property need to be added to DevTools.

Do other browser engines implement this?
Blink: Intent to implement and ship:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/6jK81erL87E/i6t4G9AaAwAJ

Tests - URLs / paths to tests (preferably web-platform-tests)
CSSWG's test repo contains some semi-manual tests, which are not usable
in our infra. I'm adding an internal reftest (not wpt or csswg test)
which uses some of our internal features to check its rendering.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Behaving Improperly to Standard

[Boris Zbarsky]

On 12/20/16 3:37 PM, Mark Legate wrote:

I wasn't satisfied with the clarity of my response so I detailed out the issue 
further:

http://pastebin.com/pvLNXXip


The heart of the misunderstanding here is this bit:

4 - The element from which the value is propagated must have a used 
value for 'overflow' of 'visible'.


Propagation to viewport happens on computed values (or specified; the 
spec is not clear on this, but for overflow computed and specified are 
the same).  Then after that used values are determined.  So in this case:


  


The following things will happen:

1)  The overflow on  is computed to "visible".
2)  The overflow on  is computed to "hidden".
3)  Per your item 2, the overflow on  is propagated to the 
viewport, giving the viewport an overflow of "hidden".
4)  Per your item 4, the used value of overflow on  is set to 
"visible".


The reason for step 4 (your item 4) is that in this situation:

  


the desired behavior is one single scrollbar, not separate scrollbars on 
the viewport and the .


-Boris

P.S. In case you care, the person you're responding to (dbaron) was 
involved in writing the spec you're citing.

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

Intent to implement: HTML5 element

[Tim Nguyen]

*Summary*:
The *HTML  element* represents a dialog box or other interactive
component, such as an inspector or window.
It will initially be implemented behind a pref.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

*Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
dialog-element

*Platform coverage*: All

*Estimated or target release*: Firefox 54

*Preference behind which this will be implemented*:
dom.dialog_element.enabled

*DevTools bug*: None yet, although I'm not sure how we can make DevTools
more useful here ?

*Do other browser engines implement this?*
Shipped: Chrome (since version 37)
Considering: Edge ( http://status.modern.ie/dialogelementformodals )

*Tests*:
https://github.com/w3c/web-platform-tests/blob/master/
html/dom/interfaces.html#L1835
https://github.com/w3c/web-platform-tests/tree/master/
html/semantics/interactive-elements/the-dialog-element
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Firefox Behaving Improperly to Standard

[Mark Legate]

I wasn't satisfied with the clarity of my response so I detailed out the issue 
further:

http://pastebin.com/pvLNXXip


On Tue, 12/20/16, L. David Baron  wrote:

 Subject: Re: Firefox Behaving Improperly to Standard
 To: "Mark Legate" 
 Cc: dev-platform@lists.mozilla.org
 Received: Tuesday, December 20, 2016, 12:56 PM
 
 On Tuesday 2016-12-20
 02:24 +, Mark Legate wrote:
 > https://www.w3.org/TR/CSS2/visufx.html#overflow
 > https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport
 > https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping
 
 And https://bugzilla.mozilla.org/show_bug.cgi?id=1322952
 
 > The logic, as I read it
 (caps added to indicate RFC language):
 >
 
 > The viewport standard recommends that
 the UA SHOULD offer a scrolling mechanism if the content is
 larger than the viewport.  The general of overflow-clipping
 outlines a situation where clipping can occur while
 position:absolute elements can remain visible.  In the
 presented situation, overflow:hidden breaks the ability of
 the user to use a scrollbar to access this content if
 it's also outside the viewport.  The overflow standard
 is a bit harder to parse, however, as I understand it, it
 requires that:
 
 By "the
 overflow standard" I assume you mean the link above
 rather
 than the css-overflow
 specification.
 
 > 1) The
 overflow property MUST be applied to the root element
 (presumably overflow:auto unless otherwise specified)
 
 Not sure what you mean by
 "be applied", but the overflow property on
 the root element is applied to the viewport,
 not to the root
 element.
 
 > 2) If a BODY/body element has an overflow
 property it MUST apply it to the viewport only if (1) is
 overflow:visible 
 
 Correct.
 
 >
 3) When (2) occurs it MUST be overflow:visible
 
 No idea what you mean by
 this.
 
 > 4) When
 overflow:visible MUST be interpreted as overflow:auto
 
 For the viewport, yes.
 
 > 5) When (4) occurs a
 scrolling mechanism SHOULD be provided (see:
 overflow:auto)
 
 Yes.
 
 > There are several things
 FF is doing that do not adhere to this standard:
 > 
 > 1) Computed values
 show it's being interpreted as overflow:visible not
 overflow:auto for the root element, this is allowing
 overflow properties to propagate from the body
 inappropriately
 
 Computed
 values are not affected by any of this fixup.
 https://drafts.csswg.org/css2/visufx.html#overflow
 says "Computed
 value:  as
 specified".
 
 > 2)
 overflow:hidden (and other values) are being propagated from
 the body element despite the standard requiring this only be
 done if the BODY/body's overflow property is set to
 'visible'
 
 I
 don't see this requirement.  The spec says:
 
   When the root element is an
 HTML "HTML" element or an XHTML
 "html"
   element, and that
 element has an HTML "BODY" element or an XHTML
   "body" element as a child, user
 agents must instead apply the
  
 'overflow' property from the first such child
 element to the
   viewport, if the value on
 the root element is 'visible'.
 
 which requires that the value on body be
 propagated to the viewport
 if the value on
 the *root* element is visible, no matter what the
 value on body is.
 
 > 3) viewport standard is ignored, possibly
 intentionally(?), however, it leaves the user without a
 scrollbar in situations where one is desired, including the
 one presented in #overflow-clipping
 
 The phrase "the user agent should offer a
 scrolling mechanism" is
 just the usual
 poorly-written spec language in CSS level 2, and it's
 overridden by the more specific language that
 actually says how
 overflow handling should
 work.
 
 > 4) overflow:auto is
 ignored both in interpretation and scrollbar
 implications
 
 No idea
 what you mean by this.
 
 But
 I'm pretty sure changing this would lead to
 unexpected
 scrollbars on large numbers of
 websites, since I believe this works
 as
 specified across browsers.
 
 -David
 
 -- 
 턞   L. David Baron         
                http://dbaron.org/   턂
 턢   Mozilla             
             https://www.mozilla.org/   턂
              Before I built a
 wall I'd ask to know
          
    What I was walling in or walling out,
              And to whom I was
 like to give offense.
            
    - Robert Frost, Mending Wall
 (1914)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows CPU power settings

[Jim Blandy]

On Fedora, that'd be the kernel-tools package, and the "cpupower
frequency-info" command, I think?


On Sat, Dec 17, 2016 at 11:04 PM, Bobby Holley 
wrote:

> It looks like there are similar (though not as bad) shenanigans on Linux.
>
> In a fresh Ubuntu install, there are two available frequency governors,
> "powersave" and "performance". The default is "powersave", which seems
> suboptimal on a Desktop Xeon. The intel_pstate driver doesn't support
> manually pegging the clock, but the "performance" governor seems generous
> enough that it probably doesn't matter.
>
> Installing cpufrequtils and then setting the governor in
> /etc/init.d/cpufrequtils to "performance" seemed to do the trick. You can
> get a live read on clock speeds with cpufreq-aperf, which should show all
> logical CPUs pegged to/near their max during a clobber build.
>
> Changing this seemed to take a clobber build from 8:45 to 8:30, though I
> didn't remeasure in powersave.
>
> HTH,
> bholley
>
> On Tue, Dec 13, 2016 at 6:31 AM, Ben Kelly  wrote:
>
> > On Mon, Dec 12, 2016 at 8:44 PM, Gregory Szorc  wrote:
> >
> > > The Windows 10 power settings appear to set the minimum CPU frequency
> at
> > 5%
> > > or 10% of maximum. When I cranked this up to 100%, artifact build time
> > > dropped from ~170s to ~77s and full build configure dropped from ~165s
> to
> > > ~97s!
> > >
> > > If you are a Windows user with Xeons in your desktop, you may want to
> > visit
> > > Control Panel -> Hardware and Sound -> Power Options -> Edit Plan
> > Settings
> > > -> Change advanced power settings -> Process power management ->
> Minimum
> > > processor state and crank that up and see what happens. Note: running
> > your
> > > CPU at 100% all the time may impact your power bill!
> > >
> >
> > FWIW, in my windows 10 Control Panel -> Hardware and Sound -> Power
> Options
> > I had 3 preset power profiles:
> >
> > * Balanced (default selected)
> > * Power Saver
> > * Performance
> >
> > The "Balanced" profile has the 5% minimum clock speed.  The "Performance"
> > profile set that to 100%.
> >
> > Ben
> > ___
> > 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: Introducing mozilla::Result for better error handling

[Ehsan Akhgari]

On 2016-12-20 8:46 AM, Jan de Mooij wrote:
> Hi all,
> 
> A few weeks ago we added mozilla::Result to MFBT [0][1].

Amazing!

> I was asked
> to inform dev-platform about this, so here's a quick overview.
> mozilla::Result is based on Rust's Result type [2]. It contains
> either a success value of type V or an error value of type E. For example,
> a function Foo that returns an `int` on success or some `Error` (enum,
> pointer, etc) on failure, would have this signature:
> 
>   Result Foo();
> 
> mozilla::Ok is an empty struct that can be used when a function doesn't
> return anything on success:
> 
>   Result Bar() { ... return Ok(); }
> 
> The MOZ_TRY(expr) macro is similar to Rust's try! macro: if `expr` is an
> error it propagates it to the caller, else it continues:
> 
>   Result Baz() { MOZ_TRY(Bar()); ... }

I have one question: what is Bar() expected to return here?  An E type,
or a type that's implicitly convertible to E
(
suggests that this is the case), or something else?  Is there a
potential for mistakes like for example caused by the error types being
implicitly convertible to each other but the values changing their
meanings upon the conversion (for example a bool error type getting
converted to an int error type)?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: RC4 disabled by default in Firefox 44

[zombie . dk89]

On Tuesday, September 1, 2015 at 11:56:28 AM UTC-5, Richard Barnes wrote:
> For a while now, we have been progressively disabling the known-insecure
> RC4 cipher [0].  The security team has been discussing with other the
> browser vendors when to turn off RC4 entirely, and there seems to be
> agreement to take that action in late January / early February 2016,
> following the release schedules of the various browsers.  For Firefox, that
> means version 44, currently scheduled for release on Jan 26.
> 
> More details below.
> 
> 
> # Current statusyour a bitch

> 
> Since Firefox 37, RC4 has been partly disabled in Firefox.  It still works
> in Beta and Release, but in Nightly and Aurora, it is allowed only for a
> static whitelist of hosts [1][2].  Note that the whitelist is not
> systematic; it was mainly built from compatibility bugs.
> 
> RC4 support is controlled by three preferences:
> 
> * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no
> restrictions
> * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for
> hosts on the static whitelist
> * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is
> allowed (empty by default)
> 
> 
> # Proposal
> 
> The proposed plan is to gradually reduce RC4 support by making the default
> values of these preferences more restrictive:
> 
> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only
> for whitelisted hosts)
> * 44: Disable all RC4 prefs by default, in all releases
> 
> That is, as of Firefox 44, RC4 will be entirely disabled unless a user
> explicitly enables it through one of the prefs.
> 
> 
> # Compatibility impact
> 
> Disabling RC4 will mean that Firefox will no longer connect to servers that
> require RC4.  The data we have indicate that while there are still a small
> number of such servers, Firefox users encounter them at very low rates.
> 
> Telemetry indicates that in the Beta and Release populations, which have no
> restrictions on RC4 usage, RC4 is used for around 0.08% for Release and
> around 0.05%  for Beta [3][4].  For Nightly and Aurora, which are
> restricted to the whitelist, the figure is more like 0.025% [5].  These
> numbers are small enough that the histogram viewer on telemetry.mozilla.org
> won't show them (that's why the below references are to my own telemetry
> timeline tool, rather than telemetry.mozilla.org).
> 
> That said, there is a small but measurable population of servers out there
> that require RC4.  Scans by Mozilla QA team find that with current Aurora
> (whitelist enabled), around 0.41% of their test set require RC4, 820 sites
> out of 211k.  Disabling the whitelist only results in a further 26 sites
> broken, totaling 0.4% of sites.  I have heard some rumors about there being
> a higher prevalence of RC4 among enterprise sites, but have no data to
> support this.
> 
> Users can still enable RC4 in any case by changing the above prefs, either
> by turning on RC4 in general or by  adding specific hosts to the
> "insecure_fallback_hosts" whitelist.  The security and UX teams are
> discussing possibilities for UI that would automate whitelisting of sites
> for users.
> 
> [0] https://tools.ietf.org/html/rfc7465
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227
> [2]
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc
> [3]
> https://ipv.sx/telemetry/general-v2.html?channels=release=SSL_SYMMETRIC_CIPHER_FULL=1
> [4]
> https://ipv.sx/telemetry/general-v2.html?channels=beta=SSL_SYMMETRIC_CIPHER_FULL=1
> [5]
> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora=SSL_SYMMETRIC_CIPHER_FULL=1

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

Re: Intent to ship: RC4 disabled by default in Firefox 44

[zombie . dk89]

On Tuesday, September 1, 2015 at 11:56:28 AM UTC-5, Richard Barnes wrote:
> For a while now, we have been progressively disabling the known-insecure
> RC4 cipher [0].  The security team has been discussing with other the
> browser vendors when to turn off RC4 entirely, and there seems to be
> agreement to take that action in late January / early February 2017,
> following the release schedules of the various browsers.  For Firefox, that
> means version 44, currently scheduled for release on Jan 26.
> 
> More details below.
> 
> 
> # Current status
> 
> Since Firefox 37, RC4 has been partly disabled in Firefox.  It still works
> in Beta and Release, but in Nightly and Aurora, it is allowed only for a
> static whitelist of hosts [1][2].  Note that the whitelist is not
> systematic; it was mainly built from compatibility bugs.
> 
> RC4 support is controlled by three preferences:
> 
> * security.tls.unrestricted_rc4_fallback - Allows use of RC4 with no
> restrictions
> * security.tls.insecure_fallback_hosts.use_static_list - Allow RC4 for
> hosts on the static whitelist
> * security.tls.insecure_fallback_hosts - A list of hosts for which RC4 is
> allowed (empty by default)
> 
> 
> # Proposal
> 
> The proposed plan is to gradually reduce RC4 support by making the default
> values of these preferences more restrictive:
> 
> * 42/ASAP: Disable whitelist in Nightly/Aurora; no change in Beta/Release
> * 43: Disable unrestricted fallback in Beta/Release (thus allowing RC4 only
> for whitelisted hosts)
> * 44: Disable all RC4 prefs by default, in all releases
> 
> That is, as of Firefox 44, RC4 will be entirely disabled unless a user
> explicitly enables it through one of the prefs.
> 
> 
> # Compatibility impact
> 
> Disabling RC4 will mean that Firefox will no longer connect to servers that
> require RC4.  The data we have indicate that while there are still a small
> number of such servers, Firefox users encounter them at very low rates.
> 
> Telemetry indicates that in the Beta and Release populations, which have no
> restrictions on RC4 usage, RC4 is used for around 0.08% for Release and
> around 0.05%  for Beta [3][4].  For Nightly and Aurora, which are
> restricted to the whitelist, the figure is more like 0.025% [5].  These
> numbers are small enough that the histogram viewer on telemetry.mozilla.org
> won't show them (that's why the below references are to my own telemetry
> timeline tool, rather than telemetry.mozilla.org).
> 
> That said, there is a small but measurable population of servers out there
> that require RC4.  Scans by Mozilla QA team find that with current Aurora
> (whitelist enabled), around 0.41% of their test set require RC4, 820 sites
> out of 211k.  Disabling the whitelist only results in a further 26 sites
> broken, totaling 0.4% of sites.  I have heard some rumors about there being
> a higher prevalence of RC4 among enterprise sites, but have no data to
> support this.
> 
> Users can still enable RC4 in any case by changing the above prefs, either
> by turning on RC4 in general or by  adding specific hosts to the
> "insecure_fallback_hosts" whitelist.  The security and UX teams are
> discussing possibilities for UI that would automate whitelisting of sites
> for users.
> 
> [0] https://tools.ietf.org/html/rfc7465
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1128227
> [2]
> https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/IntolerantFallbackList.inc
> [3]
> https://ipv.sx/telemetry/general-v2.html?channels=release=SSL_SYMMETRIC_CIPHER_FULL=1
> [4]
> https://ipv.sx/telemetry/general-v2.html?channels=beta=SSL_SYMMETRIC_CIPHER_FULL=1
> [5]
> https://ipv.sx/telemetry/general-v2.html?channels=nightly%20aurora=SSL_SYMMETRIC_CIPHER_FULL=1

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

Re: Who loves multiple selection feature in editor?

[Mats Palmgren]

On 12/20/2016 03:25 AM, Masayuki Nakano wrote:

I'm talking about only nsISelectionController::SELECTION_NORMAL. Other
selections need multiple selection.


I suspect that treating SELECTION_NORMAL differently from other kinds of
Selections will actually make the code more complicated, not less.



At this time, we need to create loop for deleting all selection ranges,
but the ranges may be changed/removed during handling other selection
ranges.


Is that due to notifying selection listeners?  If so, there is a RAII
class for blocking those until you're done: SelectionBatcher.
Anyway, I believe that we can add a few convenience methods/classes
to make this stuff easy to work with...

But let's take that code discussion off-list.  :-)


We don't have any spec how do we behave in such case.


The current spec editor seems open to discussing multi-range Selection,
which is encouraging.

Perhaps we could add something like this:

selection.forEachRange(function (range) {
  // do awesome stuff
})

Since web developers are essentially doing this today:
doAwesomeStuff(selection.getRangeAt(0));

it seems it should be an easy upgrade to do this instead:
selection.forEachRange(doAwesomeStuff);

Look, it's even shorter! :-)


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

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers 
wrote:

> Absolutely!  Let's Encrypt sounds awesome, super-easy, and the price is
> right.
>
> But I'm thinking of cases like Lavabit where a judge forced the site
> operator to release the private key.  Or the opposite - could a government
> restrict access to a site by forcing the CA to revoke certificates?  I
> guess you could just get another certificate from another CA but what if
> they are all ordered to revoke you - like in some future world government
> or something...
>

Certainly a government could do that, but it's easier to just go after the
DNS.


This example is extreme but security is not about the norm, it's about the
> fringe cases.  I just wish we could have an encryption scheme that doesn't
> need any third-party authority, before we start punishing those who don't
> use it.  That's all.
>

As long as sites are identified by domain names and want those names to be
tied to real world identities, I don't see anything like that one the
horizon (i.e., I'm not aware of any technology which would let you do it).

-Ekr



> On Tuesday, 20 December 2016 10:47:33 UTC-7, Jim Blandy  wrote:
> > Can't people use Let's Encrypt to obtain a certificate for free without
> the
> > usual CA run-around?
> >
> > https://letsencrypt.org/getting-started/
> >
> > "Let’s Encrypt is a free, automated, and open certificate authority
> brought
> > to you by the non-profit Internet Security Research Group (ISRG)."
> >
> >
>
>
> ___
> 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: Intent to deprecate: Insecure HTTP

[Cody Wohlers]

Absolutely!  Let's Encrypt sounds awesome, super-easy, and the price is right.  

But I'm thinking of cases like Lavabit where a judge forced the site operator 
to release the private key.  Or the opposite - could a government restrict 
access to a site by forcing the CA to revoke certificates?  I guess you could 
just get another certificate from another CA but what if they are all ordered 
to revoke you - like in some future world government or something...

This example is extreme but security is not about the norm, it's about the 
fringe cases.  I just wish we could have an encryption scheme that doesn't need 
any third-party authority, before we start punishing those who don't use it.  
That's all.

On Tuesday, 20 December 2016 10:47:33 UTC-7, Jim Blandy  wrote:
> Can't people use Let's Encrypt to obtain a certificate for free without the
> usual CA run-around?
> 
> https://letsencrypt.org/getting-started/
> 
> "Let’s Encrypt is a free, automated, and open certificate authority brought
> to you by the non-profit Internet Security Research Group (ISRG)."
> 
> 


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

Re: Expanding regular regression triage to include crashes?

[Daniel Veditz]

On Mon, Dec 19, 2016 at 10:00 PM, Kan-Ru Chen  wrote:

> I think the most important is to identify whether the crash bugs are
> regressions so they can be tracked accordingly.


I would guess that crash bugs filed by project Uptime are going to be (or
at least look like) regressions or they would have been filed​ previously.

I heartily endorse Anthony Hughes' "Bugzilla Socorro Lens" add-on which
embeds a crash-volume chart on every bug with a crash signature. Regression
ranges pop right out. It's so useful we should be hosting it on official
socorro/mozilla infrastructure so we don't melt down Anthony's server.
https://addons.mozilla.org/en-US/firefox/addon/bugzilla-socorro-lens/reviews/

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

Re: Firefox Behaving Improperly to Standard

[L. David Baron]

On Tuesday 2016-12-20 02:24 +, Mark Legate wrote:
> https://www.w3.org/TR/CSS2/visufx.html#overflow
> https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport
> https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping

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

> The logic, as I read it (caps added to indicate RFC language):
> 
> The viewport standard recommends that the UA SHOULD offer a scrolling 
> mechanism if the content is larger than the viewport.  The general of 
> overflow-clipping outlines a situation where clipping can occur while 
> position:absolute elements can remain visible.  In the presented situation, 
> overflow:hidden breaks the ability of the user to use a scrollbar to access 
> this content if it's also outside the viewport.  The overflow standard is a 
> bit harder to parse, however, as I understand it, it requires that:

By "the overflow standard" I assume you mean the link above rather
than the css-overflow specification.

> 1) The overflow property MUST be applied to the root element (presumably 
> overflow:auto unless otherwise specified)

Not sure what you mean by "be applied", but the overflow property on
the root element is applied to the viewport, not to the root
element.

> 2) If a BODY/body element has an overflow property it MUST apply it to the 
> viewport only if (1) is overflow:visible 

Correct.

> 3) When (2) occurs it MUST be overflow:visible

No idea what you mean by this.

> 4) When overflow:visible MUST be interpreted as overflow:auto

For the viewport, yes.

> 5) When (4) occurs a scrolling mechanism SHOULD be provided (see: 
> overflow:auto)

Yes.

> There are several things FF is doing that do not adhere to this standard:
> 
> 1) Computed values show it's being interpreted as overflow:visible not 
> overflow:auto for the root element, this is allowing overflow properties to 
> propagate from the body inappropriately

Computed values are not affected by any of this fixup.
https://drafts.csswg.org/css2/visufx.html#overflow says "Computed
value:  as specified".

> 2) overflow:hidden (and other values) are being propagated from the body 
> element despite the standard requiring this only be done if the BODY/body's 
> overflow property is set to 'visible'

I don't see this requirement.  The spec says:

  When the root element is an HTML "HTML" element or an XHTML "html"
  element, and that element has an HTML "BODY" element or an XHTML
  "body" element as a child, user agents must instead apply the
  'overflow' property from the first such child element to the
  viewport, if the value on the root element is 'visible'.

which requires that the value on body be propagated to the viewport
if the value on the *root* element is visible, no matter what the
value on body is.

> 3) viewport standard is ignored, possibly intentionally(?), however, it 
> leaves the user without a scrollbar in situations where one is desired, 
> including the one presented in #overflow-clipping

The phrase "the user agent should offer a scrolling mechanism" is
just the usual poorly-written spec language in CSS level 2, and it's
overridden by the more specific language that actually says how
overflow handling should work.

> 4) overflow:auto is ignored both in interpretation and scrollbar implications

No idea what you mean by this.

But I'm pretty sure changing this would lead to unexpected
scrollbars on large numbers of websites, since I believe this works
as specified across browsers.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: Intent to deprecate: Insecure HTTP

[Jim Blandy]

Can't people use Let's Encrypt to obtain a certificate for free without the
usual CA run-around?

https://letsencrypt.org/getting-started/

"Let’s Encrypt is a free, automated, and open certificate authority brought
to you by the non-profit Internet Security Research Group (ISRG)."


On Tue, Dec 20, 2016 at 6:38 AM,  wrote:

> This is a good idea but a terrible implementation.  I already need someone
> else's approval (registrar) to run a website (unless I want visitors to
> remember my IP addresses).  NOW I will need ANOTHER someone to approve it
> as well (the CA authority), (unless I want visitors to click around a bunch
> of security "errors").
>
> We shouldn't be ADDING authorities required to make websites.  The web is
> open and free and this proposal adds authority to a select few who can
> dictate whats a "valid" site and what isn't.
> ___
> 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: Introducing mozilla::Result for better error handling

[Nick Fitzgerald]

Thanks for getting this landed! Hooray for better error handling! \o/

On Tue, Dec 20, 2016 at 5:46 AM, Jan de Mooij  wrote:

> Hi all,
>
> A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
> to inform dev-platform about this, so here's a quick overview.
> mozilla::Result is based on Rust's Result type [2]. It contains
> either a success value of type V or an error value of type E. For example,
> a function Foo that returns an `int` on success or some `Error` (enum,
> pointer, etc) on failure, would have this signature:
>
>   Result Foo();
>
> mozilla::Ok is an empty struct that can be used when a function doesn't
> return anything on success:
>
>   Result Bar() { ... return Ok(); }
>
> The MOZ_TRY(expr) macro is similar to Rust's try! macro: if `expr` is an
> error it propagates it to the caller, else it continues:
>
>   Result Baz() { MOZ_TRY(Bar()); ... }
>
> There's also a MOZ_TRY_VAR macro that can be used when you want to store
> the return value on success. Result has isOk(), isErr(), unwrapOk(),
> unwrapErr() methods that do what you'd expect. It also has the
> MOZ_MUST_USE_TYPE annotation, so the static analysis builds will complain
> if you ignore the return value of a function that returns Result.
>
> Internally, Result uses mozilla::Variant, but there are some cases that can
> be stored more efficiently. For instance, Result just stores an
> Error* pointer and Ok is represented as nullptr. This is more efficient and
> will also make it easier to call functions that return Result from JIT
> code. The documentation [3] has more info.
>
> The long-term plan is to use Result in SpiderMonkey, to simplify our
> error/OOM handling [4][5].
>
> Many thanks to Jason Orendorff (jorendorff) for doing most of the work by
> writing the initial Result patches, and to Jeff Walden (Waldo) for his
> thorough code reviews.
>
> Jan
>
> [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1283562
> [1] https://searchfox.org/mozilla-central/source/mfbt/Result.h
> [2] https://doc.rust-lang.org/std/result/
> [3]
> https://searchfox.org/mozilla-central/rev/cc2a84852bd4e6f6d8d4d5b17b8382
> bb5d005749/mfbt/Result.h#148-158
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1277368
> [5] https://searchfox.org/mozilla-central/source/js/public/Result.h
> ___
> 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: Firefox Behaving Improperly to Standard

[Gijs Kruitbosch]

On 20/12/2016 16:12, Gijs Kruitbosch wrote:

On 20/12/2016 02:24, Mark Legate wrote:

I was directed here from a firefox bug.


For context, can you provide a link to the bug?


Mark replied:

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

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

Re: Firefox Behaving Improperly to Standard

[Gijs Kruitbosch]

On 20/12/2016 02:24, Mark Legate wrote:

I was directed here from a firefox bug.


For context, can you provide a link to the bug?

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

Firefox Behaving Improperly to Standard

[Mark Legate]

Hi All, 

I was directed here from a firefox bug.  I'll try to present the problem as 
clearly as I can.

The issue:

I recently had an issue where the scrollbar UI element was not rendering due to 
overflow:hidden being applied to the body.  The document was larger than the 
viewport but an overlay, hidden by a script/the user, doesn't allow for the 
script to execute the change to overflow:visible.  Upon digging into it I found 
the behaviour seems to be contrary to standard.

Relevant information:

https://www.w3.org/TR/CSS2/visufx.html#overflow

"UAs must apply the 'overflow' property set on the root element to the 
viewport. When the root element is an HTML "HTML" element or an XHTML "html" 
element, and that element has an HTML "BODY" element or an XHTML "body" element 
as a child, user agents must instead apply the 'overflow' property from the 
first such child element to the viewport, if the value on the root element is 
'visible'. The 'visible' value when used for the viewport must be interpreted 
as 'auto'. The element from which the value is propagated must have a used 
value for 'overflow' of 'visible'."

https://www.w3.org/TR/2011/REC-CSS2-20110607/visuren.html#viewport

"User agents for continuous media generally offer users a viewport (a window or 
other viewing area on the screen) through which users consult a document. User 
agents may change the document's layout when the viewport is resized (see the 
initial containing block).  When the viewport is smaller than the area of the 
canvas on which the document is rendered, the user agent should offer a 
scrolling mechanism. There is at most one viewport per canvas, but user agents 
may render to more than one canvas (i.e., provide different views of the same 
document). "

https://www.w3.org/TR/CSS2/visufx.html#overflow-clipping

"A descendant box is positioned absolutely, partly outside the box. Such boxes 
are not always clipped by the overflow property on their ancestors; 
specifically, they are not clipped by the overflow of any ancestor between 
themselves and their containing block"


The logic, as I read it (caps added to indicate RFC language):

The viewport standard recommends that the UA SHOULD offer a scrolling mechanism 
if the content is larger than the viewport.  The general of overflow-clipping 
outlines a situation where clipping can occur while position:absolute elements 
can remain visible.  In the presented situation, overflow:hidden breaks the 
ability of the user to use a scrollbar to access this content if it's also 
outside the viewport.  The overflow standard is a bit harder to parse, however, 
as I understand it, it requires that:

1) The overflow property MUST be applied to the root element (presumably 
overflow:auto unless otherwise specified)
2) If a BODY/body element has an overflow property it MUST apply it to the 
viewport only if (1) is overflow:visible 
3) When (2) occurs it MUST be overflow:visible
4) When overflow:visible MUST be interpreted as overflow:auto
5) When (4) occurs a scrolling mechanism SHOULD be provided (see: overflow:auto)

There are several things FF is doing that do not adhere to this standard:

1) Computed values show it's being interpreted as overflow:visible not 
overflow:auto for the root element, this is allowing overflow properties to 
propagate from the body inappropriately
2) overflow:hidden (and other values) are being propagated from the body 
element despite the standard requiring this only be done if the BODY/body's 
overflow property is set to 'visible'
3) viewport standard is ignored, possibly intentionally(?), however, it leaves 
the user without a scrollbar in situations where one is desired, including the 
one presented in #overflow-clipping
4) overflow:auto is ignored both in interpretation and scrollbar implications

Regards,

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

Re: Intent to deprecate: Insecure HTTP

[cody . wohlers]

This is a good idea but a terrible implementation.  I already need someone 
else's approval (registrar) to run a website (unless I want visitors to 
remember my IP addresses).  NOW I will need ANOTHER someone to approve it as 
well (the CA authority), (unless I want visitors to click around a bunch of 
security "errors").

We shouldn't be ADDING authorities required to make websites.  The web is open 
and free and this proposal adds authority to a select few who can dictate whats 
a "valid" site and what isn't.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: NetworkInformation

[Eric Rescorla]

On Mon, Dec 19, 2016 at 10:58 PM,  wrote:

> On Friday, December 16, 2016 at 8:33:48 AM UTC+11, Tantek Çelik wrote:
> > On Thu, Dec 15, 2016 at 11:51 AM, Boris Zbarsky <> wrote:
> > > On 12/15/16 12:20 PM, Ben Kelly wrote:
> > >>
> > >> Its more information than nothing.
> > >
> > >
> > > I'm not sure it is.  At least when you have nothing you _know_ you have
> > > nothing, so might think about other ways to find out what you want to
> know.
> > > This way you think you know something but you don't.
> >
> > Agreed with Boris. "more information than nothing" is not an absolute
> > value, when that information is deceiving, which as others have
> > pointed out in this thread, is quite likely to occur with non-trivial
> > frequency in common uses of this API (the "if bandwidth>x then slow
> > download" example proves this point).
> >
> > E.g. a high % of the time, (most of the time when I'm not at home or
> > work), I am on a 4G (high bandwidth) mifi (metered cost).
> >
> > This API would report misleading results for me 100% of the time I am
> > on my mifi, and for anyone else on a 4G mifi.
>
> But you know you are on a mifi as a user: you bought the mifi, you paid
> for the mifi's contract, you connected to the mifi. Same with hotel wifi,
> etc. which may be metered.
>
> The point of the API is to allow the end-user and the application to
> negotiate when it's best to perform a download (not to make decisions about
> what is best and what is going to cost money). There is nothing preventing
> an app from asking the user what network type would be best to perform
> synchronization over.
>
> The general assumption that WIFI is cheap and 3G/4G may be sometimes
> wrong, but it holds for most users.
>
> > Real experience, all (AFAIK) the "sync to cloud automatically" code
> > out there makes this mistake, e.g. iCloud, DropBox etc., so I've had
> > to turn all of it off or just not use it.
>
> Sure, but that goes back to Ehsan's point about perfect information: we
> can't currently get that until we get better WIFI standards or whatever.
> Until then, your mifi will look like WIFI - but that's not the APIs fault.
>
> Again, see the use cases document.
>
> > Let's learn from the error of "native" implementations/uses of this
> > kind of API / use thereof and not repeat that mistake on web,
> > certainly not ship an API that misleads web developers into doing the
> > wrong thing.
>
> The use cases document shows that native apps get this right a lot of the
> time.
>
> We are weighting the iCloud/DropBox problem against all the app examples
> given in the document. Right now, sites use a bunch of hacks to figure out
> if you are on a metered connection or not (see BBC example in the document).
>
> > >> Bluetooth networking is also a thing.
> > >
> > >
> > > That's a good point.
> > >
> > >> I think being able to distinguish this stuff provides some value even
> if
> > >> its not perfect for all cases.  And I don't see how it causes any
> harm.
> > >
> > >
> > > I think it causes harm to give people information they have no business
> > > having ("wifi" vs "ethernet") and it does harm to given them
> information
> > > that's likely to be bogus (the last hop speed in the wifi/ethernet
> cases).
> >
> > Precisely. Obvious harms:
> >
> > 1. Privacy compromise without obvious user benefit
> > 2. Causes web apps to waste user bandwidth/financial resources
> >
> > If the response to that is "but doing it right is too hard", then
> > don't do it all.
> >
> > > Maybe the answer is that we should just reconsider the set of types
> that
> > > gets exposed and how they get mapped to connection speeds
> >
> > I'm not sure that would sufficiently address harm 2.
> >
> > As far as I can tell, the only useful bit of information (as bz
> > pointed out) is the
> >
> > Am I on a cell data connection "for sure or maybe not"?
> > a) Where cell data "for sure" -> will *almost certainly cost the user*
> > b) Whereas "or maybe not" -> you have no idea whether it will cost the
> > user or not, do not make any assumptions.
> >
> > Given that the one pseudo-code example provided earlier in this thread
> > makes the mistake of using case (b) to errantly initiate bandwidth/$
> > wasting downloads (which may not even be necessary), I think this API
> > has not been well thought through in terms of actual user benefit, and
> > needs further incubation.
>
> Yeah, that's why it's currently in the WICG.
>
> > Not to mention we shouldn't even be getting to an "Intent to *ship*"
> > on something we expect to standardize that hasn't even been published
> > as a FPWD yet (which only *starts* the count-down clock to IPR
> > commitment).
>
> It was originally part of DAP, so it's actually gone through years of
> publication (first published in mid 2011):
> https://www.w3.org/TR/2011/WD-netinfo-api-20110607/
>
> All the arguments presented here also got raised by the WG, which made it
> go nowhere... so we took it to the WICG for 

Introducing mozilla::Result for better error handling

[Jan de Mooij]

Hi all,

A few weeks ago we added mozilla::Result to MFBT [0][1]. I was asked
to inform dev-platform about this, so here's a quick overview.
mozilla::Result is based on Rust's Result type [2]. It contains
either a success value of type V or an error value of type E. For example,
a function Foo that returns an `int` on success or some `Error` (enum,
pointer, etc) on failure, would have this signature:

  Result Foo();

mozilla::Ok is an empty struct that can be used when a function doesn't
return anything on success:

  Result Bar() { ... return Ok(); }

The MOZ_TRY(expr) macro is similar to Rust's try! macro: if `expr` is an
error it propagates it to the caller, else it continues:

  Result Baz() { MOZ_TRY(Bar()); ... }

There's also a MOZ_TRY_VAR macro that can be used when you want to store
the return value on success. Result has isOk(), isErr(), unwrapOk(),
unwrapErr() methods that do what you'd expect. It also has the
MOZ_MUST_USE_TYPE annotation, so the static analysis builds will complain
if you ignore the return value of a function that returns Result.

Internally, Result uses mozilla::Variant, but there are some cases that can
be stored more efficiently. For instance, Result just stores an
Error* pointer and Ok is represented as nullptr. This is more efficient and
will also make it easier to call functions that return Result from JIT
code. The documentation [3] has more info.

The long-term plan is to use Result in SpiderMonkey, to simplify our
error/OOM handling [4][5].

Many thanks to Jason Orendorff (jorendorff) for doing most of the work by
writing the initial Result patches, and to Jeff Walden (Waldo) for his
thorough code reviews.

Jan

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1283562
[1] https://searchfox.org/mozilla-central/source/mfbt/Result.h
[2] https://doc.rust-lang.org/std/result/
[3]
https://searchfox.org/mozilla-central/rev/cc2a84852bd4e6f6d8d4d5b17b8382bb5d005749/mfbt/Result.h#148-158
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1277368
[5] https://searchfox.org/mozilla-central/source/js/public/Result.h
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: Selection::setBaseAndExtent()

[Ms2ger]

Summary: Addition to the Selection API that is used by Google Docs (and
will hopefully help us improve our performance to match Chrome's)

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

Link to standard:
https://w3c.github.io/selection-api/#dom-selection-setbaseandextent

Platform coverage: all platforms

Estimated or target release: Fx53

Preference behind which this will be implemented: none

DevTools bug: no need AFAIK

Do other browser engines implement this? Chrome and Edge do; IE doesn't
(according to the bug). I have no other data.

Tests: added as part of the implementation:


Security & Privacy Concerns: none

(Please direct any further questions to Mats, who implemented the API.)

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

[PSA] [Important] Mac and Windows users of git-cinnabar, please read

[Mike Hommey]

Hi,

If you are using git-cinnabar on Mac or Windows, *and* have used `git
cinnabar download` *and* are using a version of the git-cinnabar release
branch that is less than 4 days old as of writing, please upgrade to
version 0.4.0rc2 and read the release notes:
https://github.com/glandium/git-cinnabar/releases/tag/0.4.0rc2

Sorry for the inconvenience.

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