Elements no longer have a QueryInterface method in JS

[Boris Zbarsky]

Hello all,

Now that we no longer have xbl implements="" to worry about, I have 
landed patches to remove the QueryInterface method from Element 
instances [1] and the infrastructure for exposing QueryInterface on Web 
IDL objects in general [2].  There may still be cases in which custom 
element implementations implement QueryInterface on elements, but that's 
handled entirely on the JS side, without involving C++ code in any way.


I checked that there are no calls to the C++ QueryInterface anywhere in 
our tests and did some basic code-searching to make sure I didn't find 
any, but there might in theory be issues with codepaths which are not 
tested in automation...


-Boris

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

Re: Intent to prototype: Web Speech API

[Andre Natal]

I changed the subject of this thread to properly fits the current intent.

We also moved the FAQ from gdocs to mozilla wiki [1] with more current and
updated info. I've just added more content about offline recognition and
how to use deep speech to the ones interested.

Let's just use that wiki as the main source of info about this work.

Thanks

Andre

[1] https://wiki.mozilla.org/Web_Speech_API_-_Speech_Recognition


On Mon, Oct 14, 2019 at 4:55 PM Andre Natal  wrote:

>
> Hi Henri,
>
> the API isn't available in Nightly yet since the code wasn't fully
> reviewed neither merged yet. You can follow its progress here [1] and here
> [2]. If you want to try it before it's merged, just apply the patch [2] to
> an updated gecko-dev branch, switch on the *media.**webspeech.*
> *recognition.**enable *and *media.**webspeech.**recognition.**force_enable
> *flags, and browse to that page again.
>
> Regarding the UI, yes, the experience will be exactly the same in our
> case: the user will get a prompt asking for permission to open the
> microphone (I've attached a screenshot below [3]), but in our case the
> audio will be sent to the endpoint set in the 
> *media.webspeech.service.endpoint
> *pref, which the user will be allowed to change (differently than
> Chrome). But if that's unset, it will send it to Mozilla's own server which
> is defaulted to in the code.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1248897#c18
> [2] https://phabricator.services.mozilla.com/D26047
> [3]
> https://www.dropbox.com/s/fkyymiyryjjbix5/Screenshot%202019-10-14%2016.13.49.png?dl=0
>
>
>
> On Mon, Oct 14, 2019 at 1:39 AM Henri Sivonen 
> wrote:
>
>> On Sat, Oct 12, 2019 at 12:29 PM Andre Natal  wrote:
>> > We tried to capture everything here [1], so please if you don't see your
>> > question addressed in this document, just give us a shout either here in
>> > the thread or directly.
>> ...
>> > [1]
>> >
>> https://docs.google.com/document/d/1BE90kgbwE37fWoQ8vqnsQ3YMiJCKJSvqQwa463yCN1Y/edit?ts=5da0f63f#
>>
>> Thanks. It doesn't address the question of what the UI in Firefox is
>> like. Following the links for experimenting with the UI on one's own
>> leads to https://mdn.github.io/web-speech-api/speech-color-changer/ ,
>> which doesn't work in Nightly even with prefs flipped.
>>
>> (Trying that example in Chrome shows that Chrome presents the
>> permission prompt as a matter of sharing the microphone with
>> mdn.github.io as if this was WebRTC, which suggests that mdn.github.io
>> decides where the audio goes. Chrome does not surface that, if I
>> understand correctly how this API works in Chrome, the audio is
>> instead sent to a destination of Chrome's choosing and not to a
>> destination of mdn.github.io's choosing. The example didn't work for
>> me in Safari.)
>>
>> --
>> Henri Sivonen
>> hsivo...@mozilla.com
>>
>
>
> --
>
> --
> Thanks,
>
> Andre
>


-- 

-- 
Thanks,

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

Re: Intent to prototype: Web Speech API

[Andre Natal]

Hi Henri,

the API isn't available in Nightly yet since the code wasn't fully reviewed
neither merged yet. You can follow its progress here [1] and here [2]. If
you want to try it before it's merged, just apply the patch [2] to an
updated gecko-dev branch, switch on the
*media.**webspeech.**recognition.**enable
*and *media.**webspeech.**recognition.**force_enable *flags, and browse to
that page again.

Regarding the UI, yes, the experience will be exactly the same in our case:
the user will get a prompt asking for permission to open the microphone
(I've attached a screenshot below [3]), but in our case the audio will be
sent to the endpoint set in the *media.webspeech.service.endpoint *pref,
which the user will be allowed to change (differently than Chrome). But if
that's unset, it will send it to Mozilla's own server which is defaulted to
in the code.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1248897#c18
[2] https://phabricator.services.mozilla.com/D26047
[3]
https://www.dropbox.com/s/fkyymiyryjjbix5/Screenshot%202019-10-14%2016.13.49.png?dl=0



On Mon, Oct 14, 2019 at 1:39 AM Henri Sivonen  wrote:

> On Sat, Oct 12, 2019 at 12:29 PM Andre Natal  wrote:
> > We tried to capture everything here [1], so please if you don't see your
> > question addressed in this document, just give us a shout either here in
> > the thread or directly.
> ...
> > [1]
> >
> https://docs.google.com/document/d/1BE90kgbwE37fWoQ8vqnsQ3YMiJCKJSvqQwa463yCN1Y/edit?ts=5da0f63f#
>
> Thanks. It doesn't address the question of what the UI in Firefox is
> like. Following the links for experimenting with the UI on one's own
> leads to https://mdn.github.io/web-speech-api/speech-color-changer/ ,
> which doesn't work in Nightly even with prefs flipped.
>
> (Trying that example in Chrome shows that Chrome presents the
> permission prompt as a matter of sharing the microphone with
> mdn.github.io as if this was WebRTC, which suggests that mdn.github.io
> decides where the audio goes. Chrome does not surface that, if I
> understand correctly how this API works in Chrome, the audio is
> instead sent to a destination of Chrome's choosing and not to a
> destination of mdn.github.io's choosing. The example didn't work for
> me in Safari.)
>
> --
> Henri Sivonen
> hsivo...@mozilla.com
>


-- 

-- 
Thanks,

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

Re: Passing UniquePtr by value is more expensive than by rref

[Nathan Froyd]

On Mon, Oct 14, 2019 at 3:58 AM Henri Sivonen  wrote:
> On Mon, Oct 14, 2019 at 9:05 AM Gerald Squelart  wrote:
> >
> > I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No 
> > Zero-Cost Abstractions" and there's this interesting insight:
> > https://youtu.be/rHIkrotSwcc?t=1041
> >
> > The spoiler is already in the title (sorry!), which is that passing 
> > std::unique_ptr by value is more expensive than passing it by rvalue 
> > reference, even with no exceptions!
> >
> > I wrote the same example using our own mozilla::UniquePtr, and got the same 
> > result: https://godbolt.org/z/-FVMcV (by-value on the left, by-rref on the 
> > right.)
> > So I certainly need to recalibrate my gutfeelometer.
>
> The discussion in the talk about what is needed to fix this strongly
> suggested (without uttering "Rust") that Rust might be getting this
> right. With panic=abort, Rust gets this right (
> https://rust.godbolt.org/z/SZQaAS ) which really makes one appreciate
> both Rust-style move semantics and the explicitly not-committal ABI.

With a little voodoo placement of [[clang::trivial_abi]]
(https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/,
https://reviews.llvm.org/D41039) on Pair specializations and UniquePtr
itself, one can make the by-value function look more like what you
might expect, but at the cost (!) of making the rvalue-ref function
look more like the original by-value function,
https://godbolt.org/z/A1wjl8.  I think that's a reasonable tradeoff to
make if we wanted to start using [[clang::trivial_abi]].

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

Soft code freeze for Firefox 71, Oct 14

[Pascal Chevrel]

Hi all,

We will be merging Firefox 71 from mozilla-central to beta for the first
time later today, Oct. 14.

In order to avoid invalidating the testing we get out of late Nightly
and the early Developer Edition builds and to ensure that we can roll
out Beta 71 to a wider audience with confidence, we'd like to ask that
any risky changes be avoided from Oct. 14 until after the version bump
to 72 on Oct 21.

Some reminders for the soft code freeze period:

Do:
- Be ready to back out patches that cause crash spikes, new crashes,
severe regressions
- Monitor new regressions and escalate merge blockers
- Support release management by prioritizing fixing of merge blockers

Do Not:
- Land a risky patch or a large patch
- Land new features (that affects the current Nightly version) — be
mindful that code behind NIGHTLY_BUILD or RELEASE_OR_BETA ifdefs can
lead to unexpected CI results
- Flip prefs that enable new Features that were untested in Nightly cycle
- Plan to kick off new experiments that might impact a feature's merge
readiness

Please let us know if you have any questions/concerns.

Thanks,

Release Management Team

-- 
Pascal Chevrel
Firefox Release Manager
+ Firefox Nightly community management

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

Re: Intent to implement: Cookie SameSite=lax by default and SameSite=none only if secure

[jrossainz79]

On Thursday, May 23, 2019 at 3:34:14 AM UTC-5, Andrea Marchesini wrote:
> Link to the proposal:
> https://tools.ietf.org/html/draft-west-cookie-incrementalism-00
> 
> Summary:
>   "1.  Treat the lack of an explicit "SameSite" attribute as
>"SameSite=Lax".  That is, the "Set-Cookie" value "key=value" will
>produce a cookie equivalent to "key=value; SameSite=Lax".
>Cookies that require cross-site delivery can explicitly opt-into
>such behavior by asserting "SameSite=None" when creating a
>cookie.
>2.  Require the "Secure" attribute to be set for any cookie which
>asserts "SameSite=None" (similar conceptually to the behavior for
>the "__Secure-" prefix).  That is, the "Set-Cookie" value
>"key=value; SameSite=None; Secure" will be accepted, while
>"key=value; SameSite=None" will be rejected."
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1551798
> 
> Platform coverage: all
> 
> Estimated or target release: 69 - behind pref
> 
> Preferences behind which this will be implemented:
>  - network.cookie.sameSite.laxByDefault
>  - network.cookie.sameSite.noneRequiresSecure (this requires the previous
> one to be set to true)
> 
> Is this feature enabled by default in sandboxed iframes? yes.
> 
> Do other browser engines implement this?
>  - Chrome is implementing/experimenting this feature:
> https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html
>  - Safari: no signal yet.
> 
> web-platform-tests: There is a pull-request
> https://github.com/web-platform-tests/wpt/pull/16957
> Implementing this feature, I added a mochitest to inspect cookies via
> CookieManager.
> 
> Is this feature restricted to secure contexts? no

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

Re: Passing UniquePtr by value is more expensive than by rref

[Jan de Mooij]

On Mon, Oct 14, 2019 at 8:05 AM Gerald Squelart 
wrote:

> A quick searchfox shows a few hundred by-value unique pointer's, we
> may want to look into these.
> Though I guess it's a trade-off between the expressiveness of by-value
> ("I'm stealing your value for sure") vs the more efficient but less obvious
> by-rref ("Maybe I'll take your value").
>

For what it's worth, this is what our documentation recommends [0]: "To
unconditionally transfer ownership of a UniquePtr into a method, use a
|UniquePtr| argument. To conditionally transfer ownership of a resource
into a method, should the method want it, use a |UniquePtr&&| argument."
I've definitely passed UniquePtr by value a number of times based on this
comment.

Jan

[0]
https://searchfox.org/mozilla-central/rev/6866d3a650c826f1cabd123663e84b95ee743701/mfbt/UniquePtr.h#179-186


> ___
> 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: Web Speech API

[Henri Sivonen]

On Sat, Oct 12, 2019 at 12:29 PM Andre Natal  wrote:
> We tried to capture everything here [1], so please if you don't see your
> question addressed in this document, just give us a shout either here in
> the thread or directly.
...
> [1]
> https://docs.google.com/document/d/1BE90kgbwE37fWoQ8vqnsQ3YMiJCKJSvqQwa463yCN1Y/edit?ts=5da0f63f#

Thanks. It doesn't address the question of what the UI in Firefox is
like. Following the links for experimenting with the UI on one's own
leads to https://mdn.github.io/web-speech-api/speech-color-changer/ ,
which doesn't work in Nightly even with prefs flipped.

(Trying that example in Chrome shows that Chrome presents the
permission prompt as a matter of sharing the microphone with
mdn.github.io as if this was WebRTC, which suggests that mdn.github.io
decides where the audio goes. Chrome does not surface that, if I
understand correctly how this API works in Chrome, the audio is
instead sent to a destination of Chrome's choosing and not to a
destination of mdn.github.io's choosing. The example didn't work for
me in Safari.)

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

[desktop] Bugs logged by Desktop Release QA in the last 7 days

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team in the last 7 days.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y64js7do.

Bugs logged by Desktop Release QA in the last 7 days:
*
*Firefox: about:logins
* NEW - https://bugzil.la/1587331 - Password selection focus not cleared 
after toggling show/hide when trying to select something else
* NEW - https://bugzil.la/1587372 - Password toggle button breaks after 
specifics steps in about:logins


Firefox: Address Bar
* NEW - https://bugzil.la/1587796 - [Ubuntu] Going through the signup 
process with a new sync'd account causes the URL text to appear faded 
out on RTL builds


Firefox: PDF Viewer
* NEW - https://bugzil.la/1587014 - PDF Viewer page number moves when a 
scroll is performed over it


Firefox: Protections UI
* NEW - https://bugzil.la/1586652 - The bottom of the Privacy Panel is 
cut off when browser is on the lower part of the screen
* NEW - https://bugzil.la/1586815 - Visible blank area to the bottom of 
the Shield's Tracking Protection submenu panel
* NEW - https://bugzil.la/1587042 - [linux] ETP toggle button pixelated 
on default (active) state


Firefox: Security
* NEW - https://bugzil.la/1588140 - [New Certificate] The user can't 
select multiple rows from the about:certificate page content


Core: Document Navigation
* NEW - https://bugzil.la/1588106 - [Fission] Navigating away from the 
about:compat page via address or search bar leads to tab closure
* NEW - https://bugzil.la/1588119 - [Fission] The address bar displays 
the previously accessed wepage's address instead of the current's 
webpage url after browser restart


DevTools: Netmonitor
* NEW - https://bugzil.la/1586667 - NetMonitor blocking - uppercase text 
on first letter for tooltip text from status column on blocked requests
* NEW - https://bugzil.la/1588070 - NetMonitor blocking - Indicate 
blocked requests yet before reload
* NEW - https://bugzil.la/1588076 - Netmonitor blocking - Add a button 
for removing all patterns


Cloud Services: Server: Firefox Accounts
* NEW - https://bugzil.la/1587725 - [Skyline] verification link used 
instead of verification code from about:preferences#sync


Core: Layout
Open - #1253  - 
The Bento Box button is still selected after the menu is closed


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/yyv2gfqa.


Regards,
Mihai Boldan


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

Re: Passing UniquePtr by value is more expensive than by rref

[Henri Sivonen]

On Mon, Oct 14, 2019 at 9:05 AM Gerald Squelart  wrote:
>
> I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No 
> Zero-Cost Abstractions" and there's this interesting insight:
> https://youtu.be/rHIkrotSwcc?t=1041
>
> The spoiler is already in the title (sorry!), which is that passing 
> std::unique_ptr by value is more expensive than passing it by rvalue 
> reference, even with no exceptions!
>
> I wrote the same example using our own mozilla::UniquePtr, and got the same 
> result: https://godbolt.org/z/-FVMcV (by-value on the left, by-rref on the 
> right.)
> So I certainly need to recalibrate my gutfeelometer.

The discussion in the talk about what is needed to fix this strongly
suggested (without uttering "Rust") that Rust might be getting this
right. With panic=abort, Rust gets this right (
https://rust.godbolt.org/z/SZQaAS ) which really makes one appreciate
both Rust-style move semantics and the explicitly not-committal ABI.

(I had to put a side-effectful println! in bar to make sure a call to
bar is generated, since #[inline(never)] isn't enough to prevent the
compiler from eliding calls to functions it can see do nothing.)

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

Passing UniquePtr by value is more expensive than by rref

[Gerald Squelart]

I'm in the middle of watching Chandler Carruth's CppCon talk "There Are No 
Zero-Cost Abstractions" and there's this interesting insight:
https://youtu.be/rHIkrotSwcc?t=1041

The spoiler is already in the title (sorry!), which is that passing 
std::unique_ptr by value is more expensive than passing it by rvalue reference, 
even with no exceptions!

I wrote the same example using our own mozilla::UniquePtr, and got the same 
result: https://godbolt.org/z/-FVMcV (by-value on the left, by-rref on the 
right.)
So I certainly need to recalibrate my gutfeelometer.

A quick searchfox shows a few hundred by-value unique pointer's, we may 
want to look into these.
Though I guess it's a trade-off between the expressiveness of by-value ("I'm 
stealing your value for sure") vs the more efficient but less obvious by-rref 
("Maybe I'll take your value").

And there may be other types we should examine as well?

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