Re: Intent to ship: MediaRecorder.{audio|video}BitsPerSecond

[Tom Ritter]

It's a bit hard for me to tell from the description - are these values
dependent on a user's hardware, performance of the user's computer, or
a user-chosen setting?  If so we would want to support
resistFingerprinting.

-tom

On Thu, Oct 3, 2019 at 9:54 PM Andreas Pehrson  wrote:
>
> As of Oct 4th I intend to land and ship the audioBitsPerSecond and
> videoBitsPerSecond attributes of MediaRecorder on all platforms. We've
> shipped MediaRecorder since Firefox 29.
>
> *Summary*: The audioBitsPerSecond and videoBitsPerSecond attributes of
> MediaRecorder reflect what an application has configured the MediaRecorder
> to use (and which we already ship support for doing). In case it was
> configured with a total (audio+video) bitrate, or if it was not configured
> at all, these attributes reflect what the UA has chosen to configure the
> MediaRecorder with.
>
> After starting a recording, these are again updated to reflect the current
> configuration of the MediaRecorder, since tracks are now known and the UA
> may have recalculated the chosen bitrates based on the number and kind of
> tracks that are being recorded.
>
> At the same time I'm making our MediaRecorder implementation largely
> spec-compliant. There's work in bug 1514158 as well as bug 1512175, where
> the former is focusing on these attributes and the latter focuses on mime
> type handling. We landed spec clarifications for both of these recently.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1514158
>
> *Standard*:
> https://w3c.github.io/mediacapture-record/MediaRecorder.html#dom-mediarecorder-videobitspersecond
> Clarifications were made to the spec to make this more interoperable. These
> were approved by Google. https://github.com/w3c/mediacapture-record/pull/175
>
> *Platform coverage*: All
>
> *Preference*: There is no special pref for these attributes
>
> *DevTools bug*: There is no generic devtools support for MediaRecorder
>
> *Other browsers*:
> Chrome shipped (since 49, bug:
> https://bugs.chromium.org/p/chromium/issues/detail?id=262211),
> Safari shipped MediaRecorder but no attributes yet (behind an experimental
> feature flag since TP73, bug: https://bugs.webkit.org/show_bug.cgi?id=85851)
>
> *web-platform-tests*: I'm adding one as part of bug 1514158:
> https://phabricator.services.mozilla.com/D41584
>
> *Secure contexts*: No, MediaRecorder is historically not restricted to
> secure contexts. However some APIs for getting access to the
> MediaStreamTracks needed to create a recorder are.
>
>
> Andreas Pehrson
> ___
> 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

Intent to prototype: Web Share Target

[mcaceres]

Summary: An API that allows websites to declare themselves as web share 
targets, which can receive shared content from either the Web Share API, or 
system events (e.g., shares from native apps).

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1476515
Fenix bug: https://github.com/mozilla-mobile/fenix/issues/5783

Standard: https://wicg.github.io/web-share-target/

Platform coverage: Android.

DevTools bug:  https://bugzilla.mozilla.org/show_bug.cgi?id=1586160

Other browsers: "shipped" in Chrome 71 - 
https://www.chromestatus.com/features/5662315307335680.

Web-platform-tests: requires manual tests.

Secure contexts: Yes.

Is this feature enabled by default in sandboxed iframes? No.

If not, is there a proposed sandbox flag to enable it? No.

Link to standards-positions discussion: 
https://github.com/mozilla/standards-positions/issues/176

How stable is the spec: somewhat stable, as it's shipping in Chrome. We hope by 
implementing we will tease out any additional issues and make it stable.

Security & Privacy Concerns: 
https://wicg.github.io/web-share-target/#security-and-privacy-considerations

Web designer / developer use-cases: PWAs may want to receive data from other 
apps, such as sharing a URL to Twitter or sharing an image to Squoosh. Web 
Share Target lets installed PWAs show up as entries in the Android share sheet. 
Eventually this could be extended to other platforms as they add support for 
sharing with websites (and not just native apps, as is currently the case on 
Windows and MacOS). 

Example: Please see 
https://developers.google.com/web/updates/2018/12/web-share-target
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: MediaRecorder.{audio|video}BitsPerSecond

[Andreas Pehrson]

As of Oct 4th I intend to land and ship the audioBitsPerSecond and
videoBitsPerSecond attributes of MediaRecorder on all platforms. We've
shipped MediaRecorder since Firefox 29.

*Summary*: The audioBitsPerSecond and videoBitsPerSecond attributes of
MediaRecorder reflect what an application has configured the MediaRecorder
to use (and which we already ship support for doing). In case it was
configured with a total (audio+video) bitrate, or if it was not configured
at all, these attributes reflect what the UA has chosen to configure the
MediaRecorder with.

After starting a recording, these are again updated to reflect the current
configuration of the MediaRecorder, since tracks are now known and the UA
may have recalculated the chosen bitrates based on the number and kind of
tracks that are being recorded.

At the same time I'm making our MediaRecorder implementation largely
spec-compliant. There's work in bug 1514158 as well as bug 1512175, where
the former is focusing on these attributes and the latter focuses on mime
type handling. We landed spec clarifications for both of these recently.

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

*Standard*:
https://w3c.github.io/mediacapture-record/MediaRecorder.html#dom-mediarecorder-videobitspersecond
Clarifications were made to the spec to make this more interoperable. These
were approved by Google. https://github.com/w3c/mediacapture-record/pull/175

*Platform coverage*: All

*Preference*: There is no special pref for these attributes

*DevTools bug*: There is no generic devtools support for MediaRecorder

*Other browsers*:
Chrome shipped (since 49, bug:
https://bugs.chromium.org/p/chromium/issues/detail?id=262211),
Safari shipped MediaRecorder but no attributes yet (behind an experimental
feature flag since TP73, bug: https://bugs.webkit.org/show_bug.cgi?id=85851)

*web-platform-tests*: I'm adding one as part of bug 1514158:
https://phabricator.services.mozilla.com/D41584

*Secure contexts*: No, MediaRecorder is historically not restricted to
secure contexts. However some APIs for getting access to the
MediaStreamTracks needed to create a recorder are.


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

Re: Proposed W3C Charter: Web of Things Interest Group

[Benjamin Francis]

Hi,

On behalf of the Mozilla IoT team I'd like to recommend that Mozilla
support this Interest Group charter.

There are a few topic areas I think are probably unnecessary (e.g. Thing
Templates and Scripting API), but these are all "explorations" and
non-normative deliverables. Overall the charter covers the broad topics we
would like to cover in our continued participation in this group.

We are now mainly concerned with the wording of the the proposed next WoT
Working Group charter
 which
will cover normative deliverables. I have already provided some feedback
 on that prior to AC review, in the
hope we can get it to the point where Mozilla would want to join that group
(of which we are not currently a member).

Just a reminder, the deadline for any further feedback on the Interest
Group charter is Friday 11th October.

Thanks

Ben

On Wed, 18 Sep 2019 at 01:50, L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   Web of Things Interest Group
>   https://www.w3.org/2019/07/wot-ig-2019.html
>   https://lists.w3.org/Archives/Public/public-new-work/2019Sep/0008.html
>
> The differences from the previous charter are:
>
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2016%2F07%2Fwot-ig-charter.html=https%3A%2F%2Fwww.w3.org%2F2019%2F07%2Fwot-ig-2019.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, October 11.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> -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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding windows and docshells leaked until shutdown

[smaug]

On 10/3/19 1:18 AM, Andrew McCreight wrote:

On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow  wrote:


Hi all, I need some advice.

I'm trying to enable Mochitest on debug builds of Thunderbird. It works
fine, except for the leak check, which finds a number of leaked windows
and docshells. Obviously we don't want to leak these things, but I can't
find what's holding onto them.

I've ruled out a number of likely candidates and I'm quickly running out
of ideas. Can you offer any tips or tricks that might help?

Here's an example log:

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267576044=try-comm-central=8051



What this leak checker means is that a docshell or window was created while
the test was running, but was not destroyed until after the test finished
(and we ran a bunch of GCs and CCs). However, these docshells and windows
don't show up in the leakcheck output, which means that they were cleaned
up before we shut down.


Ah, good, runtime leak :)
Runtime leaks are in general way easier to debug than leaks which are there 
until shutdown.
Add a conditional break point to the Release method of the relevant object
and see all the cases Release is called. One (or more) of the Release calls ends
up revealing where the leak is coming from.

To get access to the right C++ object, CC log is one way to get the address.





A typical cause for these is that there's some top level data structure,
often in JS but it could be in C++, too, that keeps track of every docshell
or window that is created, and does so by just adding a reference to it.
When we start shutdown, the data structure gets torn down, and we don't
leak things forever.

One small tip is that if you look at the line after the "leaked until
shutdown" message and you'll see something like this:
[task 2019-09-20T03:42:16.942Z] 03:42:16 INFO - TEST-INFO |
comm/calendar/test/browser/browser_calendarList.js | windows(s) leaked:
[pid = 1155] [serial = 38], [pid = 1155] [serial = 36], [pid = 1155]
[serial = 39], [pid = 1155] [serial = 37]

The entries like "[pid = 1155] [serial = 38]" are the descriptors we use
for windows (and docshells have a similar thing). If you search for "[pid =
1155] [serial = 38]" in the log, you can see where exactly each window was
created and destroyed. Sometimes that can give a hint about what is going
wrong.

Like Emilio said, the best approach to fixing these leaks is going to be
getting GC/CC logs from the point where it complains about the window being
alive, and then you can figure out from there what is keeping the window
alive, which may or may not point at what the leak is.

In practice, doing all of this leak fixing is rather a big project by
itself, so I'd recommend that you disable this leak checking in Thunderbird
somehow, and then just try to get the rest of the debug tests up and
running, and then maybe come back to it later. This leak checking is done
in this file (by doing postprocessing of the browser log):
testing/mochitest/leaks.py





GL
___
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